Freaks Macintosh Archive/Freaks Macintosh Archive.bin/Freaks Macintosh Archives/Textfiles/coloredbooks/PinkBook.sit.hqx/Pink Book

Text File | 1997-11-17 | 145KB | 3,512 lines

Rating Maintenance Phase Program





Rating Maintenance Phase Program



NCSC-TG-013-89


Library No.  S-232,468


Version - 1
FOREWORD



The National Computer Security Center has established an aggressive
program to study and implement computer security technology, and
to encourage the widespread availability of trusted computer products
for use by any organization desiring better protection of their
important data.  The Trusted Product Evaluation Program, and the
open and cooperative business relationship being forged with the
computer and telecommunications industries, will result in the
fulfillment of our country's computer security requirement.  We
are resolved to meet the challenge of identifying trusted computer
products suitable for use in protecting information.


"Rating Maintenance Phase Program Document" is the latest
in the series of technical guidelines published by the National
Computer Security Center.  The Rating Maintenance Phase (RAMP)
of the Trusted Product Evaluation Program provides for the maintenance
of computer security ratings across product revisions.  This document
describes RAMP for current and prospective vendors of trusted
systems.  The primary objectives are to provide formal statements
of program requirements and to provide guidance on addressing
them.


As the Director, National Computer Security Center, I invite your
recommendations for revising this technical guideline.  We plan
to review this document as the need arises.


________________


Patrick R. Gallagher, Jr.


23 June 1989

 • Director, National Computer Security Center





ACKNOWLEDGMENTS



The National Computer Security Center extends special recognition
and acknowledgment  to Tommy Hammer, Ph.D., as principal author
of this document and to LT Patricia R. Toth (USN) as project manager
for the publication of this document.


We wish to thank the following for their contributions in developing
the concepts and procedures of rating maintenance characterized
by this document: Blaine Burnham, Ph.D., David M. Chizmadia, Donald
Crossman, Major Doug Hardie, Howard Israel, Shawn P. O'Brien,
Michael J. Oehler, Mary D. Schanken, Dana Nell Stigdon, John W.
Taylor, and W. Stan Wisseman.
1. OVERVIEW OF THE RATING MAINTENANCE PHASE

1.1 BACKGROUND AND CHARACTERISTICS OF RAMP



The National Computer Security Center (the Center) evaluates commercially
marketed products against the Department of Defense Trusted Computer
System Evaluation Criteria (TCSEC) classes D through A1.  Each
evaluation by the Center yields a TCSEC class designation, or
rating, for the given product.  The Center publishes these ratings
in the Evaluated Products List (EPL), which is widely cited in
computer system procurements.  The Center thus works in partnership
with private industry to establish product trust.


The purpose of the Rating Maintenance Phase (RAMP) is to provide
currently available trusted products.  RAMP is essential for this
purpose because of the frequency with which many vendors revise
their offerings.  Vendors often market new releases of a product
every few months and keep multiple versions under development
at all times.  Without RAMP, only the initial evaluated version
is a trusted system with a TCSEC rating.  RAMP allows the Center
to establish a rating and an EPL listing for each product release
following an evaluated release.


RAMP is intended to yield an EPL listing for a revised product
shortly after its release date.  This outcome is possible because
RAMP builds cumulatively upon the evidence and assurance established
by a product evaluation, and because the vendor bears primary
responsibility in RAMP for maintaining product trust as the system
evolves.  The vendor follows strict procedures that integrate
security analysis, configuration management, and evidence accumulation
into the development process.  The Center then extends the product
rating to each successive release by ascertaining that the vendor
has executed all rating maintenance responsibilities fully and
correctly.


RAMP always builds upon a product evaluation; it provides no opportunity
to avoid an evaluation.  The program does not diminish the role
of evaluations in any sense other than reducing vendor motivation
to seek product reevaluations.  RAMP provides no opportunity for
a product release to obtain a different rating from the one held
by the original evaluated version (other than a D rating, which
terminates RAMP for the given product).
1.2 RAMP BENEFITS AND COSTS



The following are potential benefits of RAMP for system vendors:

 • 1) Vendors participating in RAMP can offer their latest products
in response to procurements that favor or require systems rated
under the Trusted Product Evaluation Program.







2) RAMP makes it easier for vendors to discontinue support of
previously rated products that have become outdated.


3) RAMP can reduce a vendor's long-term need for reevaluations
while increasing the vendor's rated product offerings.


4) RAMP can clarify a vendor's representation of a new product
version as a trusted system.


5) RAMP creates a learning process for vendors that can yield
valuable knowledge for trusted system development and marketing.

 • RAMP participation creates four general types of cost for
vendors:






 • 1) Initial expenses of personnel training and program planning.







2) Net vendor costs of establishing RAMP and undergoing a product
evaluation with RAMP.


3) Net costs of complying with RAMP procedural requirements when
developing product revisions.


4) Costs of producing the Rating Maintenance Report and conducting
related tasks to obtain rating approval.


Costs in the second and third categories largely involve the establishment
of a rigorous configuration management system for product changes.
 These net costs are highly dependent upon company policies and
procedures in the absence of RAMP, and must be judged on a case
- by - case basis from the description of the program in the following
sections.
1.3 RAMP COVERAGE



RAMP is currently available only for the maintenance of C1, C2,
and B1 ratings.  At present, a product cannot hold a B2, B3, or
A1 rating without an evaluation of the precise version in question.
 RAMP is currently directed toward operating systems.  Layered
products are also eligible if their sponsors can meet the same
requirements that apply to operating systems.  RAMP does not cover
subsystems.  The Center can accommodate the evolution of subsystem
products more appropriately through reevaluations. Networks and
network components are not eligible for RAMP at this time, pending
resolution of relevant issues for these products.


Vendor participation in RAMP is required for all products under
evaluation for a C1, C2, or B1 rating.  A vendor must establish
an intent to participate in RAMP prior to the vendor assistance
phase of an evaluation for the original product, and must then
pursue the process continuously so that successive versions of
the product are rated at the same level as the preceding version.
 (Previously evaluated products can remain on the EPL, without
RAMP involvement.)  The Center reserves the right to determine
at any point in an application of RAMP that further rating maintenance
is not viable under the program because of the nature of product
changes.  As described in Section 6, the Center provides advance
notice of such determinations whenever possible.
1.4 RAMP APPROACH



Figure 1 shows the aspects of a typical product life cycle that
create the need for RAMP.  Figure 1 does not cover participation
in RAMP (or the first two evaluation steps listed below).  The
uppermost time line depicts a vendor's development of a new product,
and the second time line describes the Center evaluation of this
release.  The sequence of events for a product evaluation without
RAMP is as follows.


1) The vendor submits an evaluation proposal package to the Center
for the given product.


2) The Center assesses the company, the marketability of the product,
and the feasibility of evaluating the product under the TCSEC.


3) The Center prepares a Preliminary Technical Report (PTR) describing
the condition of the product, its development schedule and requirements,
and its candidate rating level.


4) The vendor develops the product according to the schedule identified
in the PTR.  The Center provides assistance in meeting the intended
rating level.


5) The vendor declares a code freeze (CF) on the given release
of the product.  The code freeze is the end of substantive product
changes (as opposed to testing and fix activities).


6) The Center prepares an Initial Product Assessment Report (IPAR)
for review by the Center's Technical Review Board (TRB).  In contrast
to the PTR, the IPAR is an intensive analysis yielding an estimation
of whether or not the product is able to sustain an evaluation
at the targeted level of trust.


7) The Center conducts an evaluation wherein product trust must
be demonstrated and defended to the satisfaction of the TRB.


8) The TRB makes a rating recommendation.


9) Upon ratification by the Chief of the Product Evaluation Division,
the rating is forwarded for publication on the EPL.


10) The Center publishes a Final Evaluation Report (FER) at roughly
the same time that the product appears on the EPL.  The FER is
a summary, intended to be publicly releasable, of evidence on
product trust.


The central portion of Figure 1 describes the vendor's evolution
of the hypothetical product over time.  Long-range planning of
the product's development typically yields a prioritized list
of desirable system modifications for inclusion in releases following
the original product.   The revision process works progressively
down this list, with the number of modifications in each revision
determined by technical, financial, and marketing factors.


Figure 1 depicts a fast revision cycle in which the development
of each successive product version begins before the code freeze
for the previous release.  A slower cycle might involve the development
of each new version after the previous version is released.  As
already stated, without RAMP only the specific product version
evaluated by the Center is a trusted system with a TCSEC rating
and a listing on the EPL.  This holds regardless of the nature
of system changes, because  evaluation and RAMP are the only acceptable
mechanisms for verifying the performance and assurance of the
security features of the product.  All new releases without RAMP
continue to be unrated until such time as the product is reevaluated,
i.e., some version undergoes evaluation by the Center and thereby
receives a rating.


A goal of RAMP is life-cycle product assurance, meaning production
of evidence that the security features functionality and assurance
established in an evaluation are maintained across every system
revision.  Figure 1 shows the need for several key aspects of
RAMP.  First, life-cycle product assurance clearly requires vendor
involvement and willingness to integrate security concerns into
the system development process.  Security analysis and the assembly
of product evidence cannot be treated as intermittent or external
functions.  Second, rating maintenance activities obviously must
be established very early in the product life cycle, before the
original product is completed and work has begun on subsequent
releases.  Third, the manner in which the Center achieves rapid
turnaround of rating maintenance requests is reliance upon ongoing
procedural controls.  These controls include program planning
requirements, training of vendor personnel to perform security
analysis, and Center reviews of the rating maintenance process.


The key elements of RAMP are security analysis and configuration
management.  Security analysis is the intellectual process of
designing, analyzing, and testing product changes to assure that
they do not compromise the security characteristics of the product.
 Configuration management*defined as a process of systematically
managing changes across an entire system*is the overall procedural
framework for implementing and documenting the directives and
conclusions from security analysis.  Configuration management
provides the fundamental linkage of product evidence between the
evaluated product and each new release under RAMP.  A rigorous
configuration management system should be established prior to
the evaluation phase and applied to every product change throughout
the duration of rating maintenance.  This requirement holds for
any product in RAMP.  (Product evaluations without RAMP require
configuration management only for rating levels B2 and above.)


Figure 2 describes the general structure of RAMP.  This diagram
provides a brief overview of the topics discussed in the following
sections, and is superseded in Section 8 by a more detailed graphic
depiction of RAMP activities.  The boxes in Figure 2 are task
groupings arranged on a time scale from left to right.  The arrows
denote flows of information and program directives.


Ramp Approach - Continued


Box 1 depicts the Center evaluation of the original product.


(This document commonly refers to the evaluated product that starts
a RAMP process as the "original" product, even though
it may in fact be a reevaluated version of some earlier product.)
 The vendor has already established an intent to participate in
RAMP in the evaluation proposal package for the given product.
 While the product is still under development, one or more vendor
representatives undertake a Center training program in computer
security and RAMP requirements (box 2 in Figure 2).  A person
completing this program can serve as a Center-recognized Vendor
Security Analyst (VSA) in representing the vendor's product to
the Center.  The VSA role is a key source of product assurance
in RAMP.  (See Section 2 for a discussion of Center recognition
of VSAs.)


The vendor specifies every aspect of the vendor's RAMP process
in a Rating Maintenance Plan (RM-Plan).  The RM-Plan establishes
all procedures for maintaining product trust, including control
of changes to the RM-Plan itself.  The RM-Plan can be tailored
to the vendor's preexisting business practices, but it must be
followed precisely throughout the product life under RAMP.  Preparation
of the RM-Plan (box 3 in Figure 2) begins as soon as the vendor
has gained a sufficient understanding of rating maintenance.
The RM-Plan must be approved by the Center before the Center's
issuance of an IPAR for the original product.  The RM-Plan must
be in force before development begins on the version that will
supersede the evaluated version.


The activities depicted by boxes 4 through 6 in Figure 2 recur
for each product revision.  (Box 3 recurs whenever the RM-Plan
is changed.)  Rating maintenance actions*box 4*are configuration
management tasks conducted entirely by the vendor.  These actions
include:  examining proposed system changes for security relevance;
analyzing the direct and indirect impacts of changes; giving instructions
for the implementation of changes; monitoring the implementation
process; testing the revised system; modifying the tests as necessary;
and updating all documentation to reflect each change.  A VSA
conducts, supervises, or monitors each of these tasks.


The vendor's RAMP process is subject to two types of reviews by
the Center (box 5).  The Center conducts an interim review after
the start of rating maintenance for each new product revision.
 These interim reviews may or may not involve site visits after
RAMP has operated for one or more releases.  The Center also conducts
aperiodic on-site reviews.  Both types of program review have
the purpose of assuring that security features functionality and
assurance are being maintained by adherence to all the procedures
established in the RM-Plan.  Both reviews serve the mutual interest
of the vendor and the Center in identifying problems quickly so
that the vendor can initiate corrective actions in a timely manner.


The Center assigns a Technical Point of Contact (TPOC) to advise
and coordinate the use of RAMP for the given product.  A Center
Business Point of Contact (BPOC) handles administrative and programmatic
aspects of the process.  A Responsible Corporate Officer represents
the vendor in administrative matters.  The Responsible Corporate
Officer is a person empowered to commit the company financially
to the program and support the technical role of the VSA.  Sections
2 and 5 describe these persons and their interactions in greater
detail.


Box 6 in Figure 2 covers the submission and review of evidence
for a completed revision.  The vendor submits to the Center a
Rating Maintenance Report (RMR) containing a summary of product
evidence.  Following an initial review for completeness and general
adequacy, the RMR is forwarded to the Center's Technical Review
Board (TRB).  The VSA or VSAs associated with the product then
defend the RMR and other evidence before the TRB.  The remaining
steps in a successful application of RAMP include a recommendation
by the TRB, a rating approval by the Chief of the Product Evaluation
Division, and a product listing on the EPL.  The process is designed
so that, if all the vendor's preparations are complete and accurate,
only a short time should elapse between the end of the initial
RMR review and the listing of the product on the EPL.
1.5 LINKAGES BETWEEN RAMP AND EVALUATION



The establishment of RAMP is tied to the evaluation process at
four points.  First, the vendor must include an intent to participate
in RAMP as part of the evaluation proposal package that starts
the evaluation process.  Second, the Preliminary Technical Report
(PTR) prepared by the Center establishes the ability of the vendor
to conduct RAMP activities.  The PTR examines the vendor's understanding
of configuration management; explains the implications of the
TCSEC for the given product; and advises the vendor about the
contents of the RM-Plan.


Third, the Center does not complete an Initial Product Assessment
Report  (IPAR) for a product covered by RAMP until an RM-Plan
is approved.  A section of the IPAR confirms the adequacy of the
RM-Plan and the vendor's ability to comply with all provisions
of the plan.


Fourth, the vendor of a product in RAMP prepares a RAMP audit
to support the  evaluation by the Center.  The RAMP audit is discussed
in Section 3.  The Center conducts three TRB sessions.   During
the first session, at the end of the Design Analysis Phase,  the
IPAR is reviewed.  The second and third TRB sessions occur during
the Evaluation Phase.  The second session covers product testing.
 The third is a final, comprehensive session.  The initial RAMP
audit must be evaluated and approved at the second TRB session.
 (The program assessment  performed at this time constitutes the
first RAMP interim review.  See Section 5 for further discussion
of interim reviews.)  The RAMP audit is treated at that time as
an integral part of the functional testing requirement (test suite)
for the product.  This is one of several respects in which RAMP
participation increases the evaluation effort for both the vendor
and the Center.
1.6 APPLICABILITY OF RAMP



The following table summarizes RAMP eligibility in terms of product
type.
RAMP ELIGIBILITY BY TYPE OF PRODUCT



 Eligible Products  Ineligible Products


 Operating Systems   Subsystems


    Layered products, if vendor   Networks

 • demonstrates knowledge of base
 • product consistent with RAMP
 • requirements*







*See Sections 3 and 7


A vendor must satisfy the RAMP requirements summarized in the
Appendix.  These requirements are linked to the timing of the
product evaluation and are determined as the evaluation proceeds.
 A vendor failing to satisfy these requirements loses the opportunity
to participate in RAMP until such time as the product in question
is reevaluated.
1.7 DOCUMENT CONTENTS



The organization of material in the remainder of this document
generally follows the numbering of boxes in Figure 2.  The one
exception is that description of the RM-Plan is deferred until
all subjects covered by the plan have been discussed.


Section 2 addresses the training of vendor personnel as VSAs.



(Description of the VSA role continues in Sections 4 through 6.)
 Rating maintenance actions are the subject of Sections 3 and
4.  Section 3 discusses the conceptual aspects of configuration
management in RAMP, and Section 4 addresses procedural issues.
 Section 5 deals with program reviews and the structure of RAMP
in terms of communication and accountability.  Section 6 covers
the presentation of evidence for a product revision and the steps
leading to a rating determination.  Section 7 describes the contents
of the RM-Plan.  Section 8 provides an overview of the RAMP process.
 The Appendix summarizes the vendor's and the Center's requirements
for RAMP.
2. VENDOR PERSONNEL

2.1 INTRODUCTION



RAMP defines two roles for vendor personnel:  the Vendor Security
Analyst (VSA) and the responsible corporate officer.  At least
one Center-recognized VSA, and a responsible corporate officer,
must be maintained while rating maintenance actions are underway.
 The use of multiple persons in the VSA role is a practical necessity
for some products.  Vendors choosing to use multiple VSAs must
designate one of these persons as the lead VSA and must maintain
clearly defined areas of VSA responsibility.


VSAs are responsible for the execution of all technical tasks
in RAMP including the presentation and defense of product evidence.
 Other persons can participate in RAMP tasks at the discretion
of the vendor, but only VSAs can represent the RAMP process technically
to the Center.  The ability of RAMP to yield timely rating approvals
for an evolving product depends heavily upon the credibility and
expertise of the responsible VSA or VSAs.  These VSA characteristics
are acquired and demonstrated through the VSA training program
and the operation of the RAMP process.


The responsible corporate officer provides overall management
of the vendor's RAMP effort and serves as the point of corporate
responsibility for RAMP to the Center.  The responsible corporate
officer designates persons as VSAs; oversees the nonresident phase
of VSA training; establishes VSA responsibilities; communicates
with the Center on administrative and programmatic issues; and
provides corporate assurance that the RM-Plan and submissions
of evidence accurately describe the vendor's RAMP process.  Any
misrepresentation of the process places the product rating at
risk, reflecting upon both the responsible corporate officer and
the VSAs involved.  The responsible corporate officer must occupy
a sufficiently prominent position in the corporate structure to
bear this responsibility and to commit the necessary company resources
to RAMP.


This subsection addresses the VSA training program, the establishment
of VSA credibility, and the program requirements pertaining to
multiple VSAs.  The next four subsections describe VSA duties
and responsibilities in more specific terms.  Section 7 then discusses
the establishment of the VSA role in the RM-Plan, and Section
 8 covers Center and vendor responses to failures in this role.
2.2 SELECTION AND RECOGNITION OF VSAS



While the vendor will probably employ numerous technical personnel
in support of product development and maintenance, the Center
only recognizes as RAMP representatives those individuals who
have completed the VSA training program and are named by the vendor's
RM-Plan as VSAs.  Only these Center-recognized VSAs and the responsible
corporate officer can interact with the Center on behalf of the
product.


The remainder of this subsection discusses criteria that should
be considered by the responsible corporate officer when selecting
personnel who will support the technical development or maintenance
of a product (to include both VSAs and other technical personnel).
 Additional criteria, applying only to VSAs, are discussed in
the next subsection, Admission To Training Program.


Recommended Criteria for Vendor Selection of Technical Personnel:

 • 1) Knowledge of the product on which the person will work.







2) Knowledge of computer science and computer security.


3) Corporate position and expected longevity of association with
the vendor and the given product.


4) Time availability for involvement in RAMP tasks.


5) Contribution to multiple-VSA strategy (if used).


Regarding the first two criteria, the emphasis of RAMP upon VSA
capability provides strong motivation for vendors to staff this
function with the most knowledgeable persons available.  The third
and fourth criteria are practical considerations of obvious significance
and are particularly relevant to personnel serving as VSAs.  Problems
can result from relying upon persons at either end of the corporate
hierarchy.  Low-ranking persons may lack sufficient authority
and influence to fill the VSA role effectively, whereas high-ranking
persons may not have enough time for day-to-day participation
in rating maintenance tasks.  Ideally, a VSA should be devoted
full-time to the security analysis and rating maintenance of the
given product.  Continuity of involvement is critical because
smooth operation of RAMP depends upon the progressive establishment
of VSA credibility with the Center.


The last criterion covers such possibilities as using backup VSAs,
establishing mentoring relationships among VSAs, and selecting
VSAs to fill specialized roles within the RAMP process.
2.3 ADMISSION TO TRAINING PROGRAM



Vendors should submit VSAs for training by the Center as soon
as possible when planning to use RAMP.  The Center views timely
involvement in the training program as an indicator of vendor
commitment to the RAMP process.  The responsible corporate officer
sends a written request for vendor training with a statement of
qualification for each potential trainee.  (Ideally, the responsible
corporate officer also undergoes training.)  The Center strongly
urges vendors to submit candidates with the following qualifications:


General:

 • 1) Participants in the Center training program should have
sufficient background in computer science to analyze all aspects
of system design including functional hardware logic and software
code.







2) A trainee should be knowledgeable about the specific product
for which he or she will serve as VSA.  (A person can possibly
serve as a Center-recognized VSA for multiple products, but at
any given time the Center only deals with a VSA as a representative
of a specific product.)

 • Specific:






 • 3) A trainee should have obtained a degree from a four- or
five-year college program with a major in computer science, engineering
, or other technical field that emphasizes computer science;
 • OR, a trainee should have at least five years of professional
experience working with computers in a design or analytical capacity.






 • 4) A trainee should have at least one year of experience with
the specific product for which she or he will serve as VSA.





2.4 CENTER TRAINING PROGRAM



The VSA training program addresses the following subject areas:



general principles of computer security; requirements and Center
interpretations of the TCSEC; security issues in the system development
process; and all aspects of RAMP.  The calendar time required
for a trainee to complete the course depends upon scheduling factors
but should not exceed two months given an adequate time commitment.
 It is not possible in such a period to train persons as security
evaluators capable of conducting an unsupervised product evaluation;
but the course does impart sufficient capability to establish
product trust when working from an evaluated system.  The Center
assumes no responsibility for the selection of a VSA and, in particular,
the consequences of an inappropriate selection of a VSA by a vendor.
 The Center training program is provided as an additional measure
to help the vendor prepare and select appropriate personnel to
serve as VSAs who will, in turn, increase the likelihood that
the vendor will be able to maintain a given product's level of
trust.  The Center's principal concern is, and will remain, the
maintenance of a product's rating, not the certification of a
VSA.  For this reason, the Center will assist in the training
of, but will not formally certify, VSAs.


The training program currently consists of a three-week program
of study conducted at facilities in the Baltimore/Washington,
D.C., area.  Beginning in 1990 the Center plans to implement a
dual-phase program, which will include a nonresident (correspondence)
phase and a resident phase (with the former always occurring first).


The remaining description of the Center training program describes
the planned implementation of the dual-phase program.  The current
Center residence program incorporates all resident testing and
assessment of VSAs.


The nonresident portion of the training program does not require
a classroom setting and can take place at any location convenient
to the vendor and the trainees.  The flexibility of this phase
with regard to location and scheduling allows the training program
to be driven by vendor demand.  However, the course requires a
significant block of time and cannot simply be scheduled around
an employee's normal workload.  The responsible corporate officer
must take responsibility for assuring that each trainee has adequate
time for the program.  In addition, the nonresident phase will
not begin until the vendor has provided for VSA utilization of
the Center's Dockmaster information system (described in Section
5).


The materials utilized in the nonresident phase of the training
program include:

 • 1) documents prepared by the Center for use in the course;







2) additional required and recommended readings; and


3) tests covering the course documents and required readings.


A vendor representative serves as proctor for the nonresident
coursework.  The proctor monitors the progress of each trainee
and administers tests and written assignments.  The responsible
corporate officer designates the proctor, monitors the conduct
of the course, and provides assurance to the Center that all aspects
of the nonresident phase are executed conscientiously.  A Center
training point of contact is available to answer technical and
administrative questions about the program.


Trainee performance in the nonresident phase is evaluated on the
basis of tests, written assignments, and open-book group projects.
 The tests cover the course documents and required readings.
These materials are forwarded to the vendor with guidelines for
interpreting results, such as the scores that constitute satisfactory
performance on each test.  The vendor has responsibility for determining
that a trainee has mastered the nonresident coursework sufficiently
to enter the resident phase.


Trainees then undertake approximately one week of resident classwork
at the Center facility in Maryland.  The resident phase focuses
upon a worked example of a Trusted Computing Base (TCB), designed
to provide practical experience in security analysis.  The related
course materials include a sample RM-Plan and a sample Rating
Maintenance Report.  Trainees are evaluated in this phase by written
assignments and an oral examination that takes the form of a product
defense before a mock Technical Review Board (TRB).


The Center will notify the vendor of each trainee's performance
in the resident phase and offer a recommendation as to whether
or not the given person should be used as a VSA.  The assessment
provided will note the VSA's performance using both an absolute
scale of reference (i.e., raw scores on tests) as well as a relative
scale (i.e., the VSA's performance as compared to other VSA candidates
who have attended the training).  These scores will be supplemented
by a subjective assessment of the candidate VSA's performance.
 In the case of a weak candidate, the Center may indicate that
using the given person as a VSA will jeopardize the vendor's RAMP
process.  The vendor makes the final decision in this regard.
 The only absolute requirements for Center recognition of a vendor
representative as a VSA are:  1) completion of both phases of
the training program, and 2) assignment of VSA responsibilities
to the given person in the vendor's RM-Plan (discussed later).


The VSA training program addresses general principles of computer
security and system development, and is not product-specific.
 In the event a VSA becomes a vendor representative for some other
product, the training program need not be repeated.
2.5 FURTHER ESTABLISHMENT OF VSA CREDIBILITY



Smooth operation of the RAMP process requires a higher level of
VSA credibility and expertise than can be established in classroom
training alone.  In each RAMP cycle, vendors must demonstrate
to the satisfaction of the Technical Review Board (TRB) that security
analysis has been conducted thoroughly and correctly according
to the RM-Plan.  This demonstration involves written evidence,
VSA defense of the evidence, and VSA credibility based upon past
performance in RAMP.  The higher the level of demonstrated VSA
capability, the less need for time-consuming examination and information
requests, and the less risk of a negative rating determination.


A practicing VSA builds credibility through program reviews and
presentations to the TRB.  The former includes interim reviews
during every RAMP cycle and aperiodic reviews on a less frequent
basis.  The Center places major emphasis on a VSA's first interim
review.  (See Section 5.)  In the first presentation of evidence
by a VSA, the TRB examines the VSA's understanding of the product
as well as the management of changes under RAMP.  The topics of
questioning include: 1) the product and its security features
and assurances; 2) the procedures followed in applying RAMP on
a day-to-day basis; and, 3) the substance and rationale of decisions
regarding product changes.  Section 6 provides further discussion
of the evidence submission process.


Vendors are made aware of any VSA credibility problems through
TRB recommendations and other communications between the Center
and the responsible corporate officer.  A VSA who knowingly misrepresents
any aspect of rating maintenance for a product will no longer
be recognized by the Center as a RAMP participant for any product.
 Furthermore, when a vendor (responsible corporate officer) allows
a misrepresentation to occur, the RAMP process is terminated with
no rating approval for the product version that was misrepresented.
 The Center then reviews the previous cycles of rating maintenance
to determine whether the rating should be rolled back across earlier
releases.  (See Section 8.)  Lesser infractions consisting of
inadvertent VSA errors and oversights can yield serious delays
and uncertainties in rating approval.  Overall, there is strong
vendor self-interest in using VSAs who can establish and maintain
a high level of credibility with the TRB.
2.6 MULTIPLE VSAS



Vendors can often benefit from using more than one Center-recognized
VSA for a given product.  The multiple-VSA approach supports program
continuity in the event that a VSA becomes unavailable for duty
or proves to be deficient in some respect.  For some products,
multiple VSAs may be essential in order to assign separate responsibility
for different production sites, different parts of a product,
or different aspects of rating maintenance.  A vendor may also
employ some VSAs without assigning them any official responsibilities
in the RM-Plan.  The vendor can use such persons in backup, apprenticeship,
or other supporting roles while limiting the number of product
representatives.


The Center encourages the use of multiple VSAs subject to the
conditions stated in the following paragraphs.  These conditions,
and all further references to VSAs in the present document, pertain
just to Center-recognized VSAs who have completed the training
program and are assigned RAMP responsibilities in the RM-Plan.
 Other VSAs can be deployed freely by the vendor in the same fashion
as regular employees but cannot interact directly with the Center.


The Center must know at all times which VSAs are representing
the product and precisely what their individual responsibilities
are.  At least one Center-recognized VSA must be representing
the product at any time that rating maintenance actions are underway.
 The RM-Plan should describe the primary area of responsibility
for each VSA in such a fashion that all RAMP activities are covered
and there is no ambiguity as to who is answerable for any given
aspect.  Divisions of responsibility by production site or corporate
department should be noted along with divisions of responsibility
by RAMP task.  VSA responsibilities cannot be altered without
formally changing the RM-Plan to describe the new assignments.
 As described in Section 7, the vendor must obtain approval for
any change in the RM-Plan from the Center Technical Point of Contact.
 The RM-Plan approval constitutes the Center's recognition of
any VSAs named for the first time as responsible representatives
of the RAMP process.  Vendors are urged to make any changes in
VSA responsibilities at the beginning of a rating maintenance
cycle, i.e., within a month after the previous rating approval.


Every recognized VSA must sign the Rating Maintenance Report and
be prepared to defend product evidence for the given cycle before
the TRB.  Ultimate responsibility for the RMR rests with the responsible
corporate officer.  Other VSA duties can be conducted by one rather
than all VSAs.  For example, only one VSA need be a member of
the Configuration Control Board.  (See Section 4.)  Vendors should
nevertheless be aware that the use of multiple VSAs does not lessen
the degree to which each is accountable.  An application of RAMP
is only as strong as its weakest link in terms of VSA credibility.


A vendor using multiple VSAs must designate one person as the
lead VSA.  Most technical communication between the vendor and
the Center involves the lead VSA.  The Center may require at its
discretion that all technical communication be routed through
the lead VSA during some or all of the RAMP cycle.  It is logical
but not necessary for the lead VSA to have supervisory powers
over other VSAs.  The RM-Plan should describe any supervisory
or coordinating relationships among VSAs.  These issues are discussed
further in Sections 5 and 7.
3. SECURITY ANALYSIS AND CONFIGURATION MANAGEMENT

3.1 SECURITY ANALYSIS



Security analysis is the intellectual core of rating maintenance.



Configuration management is the supporting framework that assures
an accurate translation of security analysis findings into implemented
product changes and evidence of product trust.  Security analysis
can be viewed as an aspect of configuration management (or configuration
control).  The present document maintains a distinction between
these concepts because for many persons configuration management
connotes a set of mechanical procedures rather than a thought
process.


Security analysis is closely associated with design tasks that
would be needed to effect product changes whether or not a product
was a trusted system.  RAMP not only introduces security as a
design consideration but also requires security to be the dominant
consideration.  RAMP does not permit any compromise of security
for the sake of other product design criteria such as performance,
cost, and marketability.  There can be negotiation among possible
ways of implementing security for a given change, but no tradeoff
of security features and assurances against other objectives.
 The dominance of security is always an integral part of security
analysis as referenced here.


Security analysis draws upon the vendor's full understanding of
the function and interrelationships of security features in the
product.  This understanding is applied in diverse ways that do
not permit description of security analysis as a standardized
set of procedures.  The following paragraphs indicate briefly
the activities, issues, and outcomes of security analysis for
a typical product.


Security analysis starts by establishing the precise nature of
all effects of a product change upon the Trusted Computing Base
(TCB). (There may or may not be a separate, preliminary screening
for the existence of TCB effects; see Section 4.)  As defined
by the TCSEC, the TCB is the totality of protection mechanisms
*including hardware, firmware, and software*that together enforce
a security policy.  The present document uses a somewhat different
definition covering all system elements that support protection
mechanisms.  The TCB addressed by security analysis and configuration
management in RAMP includes system code, tests, associated software
tools, test plan documentation, test results, the trusted facility
manual, the security features user's guide, and design documentation.
 (For hardware, the program relies upon functional testing rather
than configuration management.)


A product change affects the TCB if it:  alters code or documentation
within the identified TCB boundary; augments the contents of the
TCB; or indirectly affects the function of TCB elements.  The
determination of indirect effects on the TCB is a critical aspect
of security analysis.  The analysis considers any possibility
of effects due to interrelationships among the product's security
features.  The analysis also acknowledges and assesses cumulative
effects involving multiple product changes.  (For example, two
otherwise acceptable changes may conflict in terms of security
because one change assumes conditions that no longer hold, given
the other change.)  Security analysis can potentially identify
many different TCB effects resulting from a proposed change to
a single configuration item.


Security analysis enters a design mode once all TCB effects are
identified and understood.  The requirement is then to verify
that a proposed change can be implemented without compromising
the security features and assurances of the product, or else to
remove the change from consideration.  The security analysis assures
that any change is consistent with approved architectures and
does not circumvent defined security policy.  The process of addressing
these criteria is usually integrated or coordinated with the pursuit
of other design objectives, but security is always the paramount
concern.  Depending upon the nature of the change and the vendor's
business practices, this phase of security analysis may or may
not extend into code-level product development tasks.  (See Section
4.)  Security analysis includes checking the adequacy of existing
system tests as affected by each proposed change.  The analysis
modifies existing tests or creates new tests as necessary to maintain
the effectiveness of the test suite.


The outputs of security analysis include:  instructions for implementing
changes; recommendations for rejecting other changes; new tests
and test documentation; and descriptions of all identified TCB
effects, related analytical findings, and design decisions.  The
RAMP process subjects the conclusions of security analysis to
two stages of review and retains all of the above outputs in the
configuration management system.  Security analysis is also addressed
by the RAMP audit function described at the end of this section.
3.2 OVERVIEW OF CONFIGURATION MANAGEMENT



Configuration management is a discipline applying technical and
administrative direction to:  1) identify and document the functional
and physical characteristics of each configuration item for a
product; 2) manage all changes to these characteristics; and 3)
record and report the status of change processing and implementation.
 Configuration management involves process monitoring, information
capture, quality control, bookkeeping, and an organizational framework
to support these activities.  The "configuration" being
managed is the TCB plus all tools and documentation related to
the configuration management process.


The overall objectives of configuration management in RAMP are
to assure that the findings of security analysis are implemented
correctly, and to generate product evidence linking with the evidence
established in the evaluation.  Configuration management records
the "footprint" of the security analysis and controls
and documents all subsequent rating maintenance tasks.  This involves
the central direction of system changes to:

 • 1) maintain the integrity of system information and the standards
affecting its accuracy, timeliness, and reliability;







2) ensure that documentation and tests remain congruous with the
rest of the system;


3) ensure adequate testing of changes prior to incorporation;


4) maintain the integrity of all system interfaces; and


5) support the objective of security analysis.


Many vendors of products rated C1 through B1 already use some
form of configuration management before participating in RAMP.
 The existing procedures can often meet RAMP requirements with
few modifications, although fundamental changes are sometimes
needed.  The RAMP requirements are sufficiently flexible to accommodate
substantial variations in vendor business practices.  Typically,
the greatest deficiencies of existing practices relative to RAMP
standards involve security analysis rather than the record-keeping
aspects of configuration management.


The four major aspects of configuration management are configuration
identification, configuration control, configuration status accounting,
and configuration auditing.  The present section summarizes these
activities in conceptual terms.  Section 4 then addresses procedural
issues in rating maintenance using a representative business model
to discuss specific functions needed for RAMP.
3.3 CONFIGURATION IDENTIFICATION



Configuration management entails decomposing the TCB into identifiable,
understandable, manageable, trackable units known as configuration
items (CIs).  The decomposition process is called configuration
identification.  To support RAMP, this process must occur before
the initial RM-Plan is completed so that the plan can include
the CIs for the original product.  The configuration of the evaluated
system is thereby established as a baseline for assessing future
changes.


CIs can vary widely in size, type, and complexity.  Although there
are no hard-and-fast rules for system decomposition, the granularity
of CIs can have great practical importance.  Selecting CIs that
are too small can impede the audit process by yielding an unmanageable
volume of identifying data.  Overly large CIs can hinder configuration
management by obscuring product changes and interrelationships
among changes.  A potentially favorable strategy is to designate
relatively large CIs for system elements that are not expected
to change over the life of the product, and small CIs for elements
likely to change.  System identification ideally should begin
early in the design stage for a product when CIs are most readily
established on a logical basis.  For example, each CI might be
a module of code designed to meet one requirement.  Regardless
of the strategy for establishing CIs, the granularity of control
is defined to be the module level.  The process must allow for
the possibility that system changes will convert non-CI components
into CIs.


Vendors in RAMP decompose at least the following system components
into CIs and assign a unique identifier to each.

 • 1) Software and firmware components of the baseline (evaluated)
TCB.







2) Design and user documentation.


3) Software tests including functional and system integrity tests
and associated documentation.


4) Development tools including any configuration management tools.


5) Any tools used for generating current configuration items.


6) Any audit trail reduction tools used in the configuration management
context.


7) Any other components of the TCB as broadly defined.


Throughout the application of RAMP to product revisions, each
change in a configuration item is uniquely identified.  The changes
of significance for RAMP are any alterations to the TCB since
the product evaluation.  The date of a CI change is identifiable
along with any changes to the related documentation, tests, or
development tools.  Each change in software source code is separately
identifiable, although changes need not be separately stored.
3.4 CONFIGURATION CONTROL



Configuration control is a means of assuring that system changes
are approved before being implemented, that only the proposed
and approved changes are implemented, and that the implementation
is complete and correct.  This involves strict procedures for
proposing, monitoring, and approving system changes and their
implementation.  Configuration control entails central direction
of the change process by corporate functions that coordinate analytical
tasks, approve system changes, review the implementation of changes,
and supervise other tasks such as documentation.  These procedural
requirements of RAMP are the primary subject of Section 4.


Configuration control involves not only the approval of changes
and their implementation but also the updating of all related
material to reflect each change.  There should be guidelines for
creating and maintaining functional test software and documentation
throughout the life of the system.  The change process should
include a phase for test creation and maintenance, with associated
updating of documentation.  Relevant tests should be performed
and evaluated whenever system changes are implemented and/or tests
are updated.  The vendor must rerun the entire test suite before
submitting RAMP evidence to the Center.


A vendor's production arrangements may hinder or complicate the
process of controlling system change.  Hardware and software may
be developed by separate groups within the vendor organization,
perhaps located at different sites.  Code development and integration
may occur in different cities, with testing conducted at both
locations.  Also, a vendor may propose RAMP for a system (layered
product) that incorporates another vendor's products.  Vendors
faced with these difficulties acknowledge the resulting limitations
on security analysis and configuration control in their RM-Plans,
and establish alternative procedures of equal effectiveness for
upholding product trust.


A vendor applying RAMP to a layered product demonstrates configuration
management cognizance over all parts of the product, including
parts manufactured by other vendors.  This means that the vendor
understands the base product and its changes since evaluation
and conducts security analysis of these changes, to the same extent
as required by RAMP for an in-house product.  (See Section 7.)
  Some form of collaboration among vendors is thus virtually essential
for RAMP coverage of a layered product.


A vendor's configuration management system includes policies and
procedures for correcting any security bugs identified in the
product.  Responses to flaws, bugs, and breakdowns of RAMP assurance
are discussed in Section 8.
3.5 CONFIGURATION ACCOUNTING



Configuration accounting documents the status of configuration
control activities and in general provides the information needed
to manage a configuration effectively.  It allows managers to
trace system changes and establish the history of any developmental
problems and associated fixes.  Configuration accounting also
tracks the status of current changes as they move through the
configuration control process.  Configuration accounting establishes
the granularity of recorded information and thus shapes the accuracy
and usefulness of the audit function.


Configuration accounting should yield answers to questions such
as the following.  What source code changes were made on a given
date?  Was a given change security relevant?  Why or why not?
 What were all the changes in a given CI between releases N and
N+1?  By whom were they made, and why?  What other TCB modifications
were required by the changes to this CI?  Were modifications required
in the test set or documentation to accommodate any of these changes?
 What were all the changes made to support a given change request?


The accounting function is able to locate all possible versions
of a configuration item and all of the incremental changes involved,
thereby deriving the status of that CI at any point in time.
The associated records include commentary about the reason for
each change and its implications for the TCB.  Configuration accounting
provides convenient access to such records for use as evidence
in the rating maintenance process.  In general, the effectiveness
of configuration accounting depends upon the quality of system
identification and control efforts.
3.6 CONFIGURATION AUDIT



Configuration audit is the quality assurance component of configuration
management.  It involves periodic checks by the vendor to determine
the consistency and completeness of accounting information and
to verify that all configuration management policies are being
followed.  (The following subsection identifies when configuration
audits occur.)  A vendor's configuration management program must
be able to sustain a complete configuration audit by a Center
aperiodic review team.


A configuration auditor should be able to trace a system change
from start to finish.  The auditor should check that only approved
changes have been implemented and that all tests and documentation
have been updated concurrently with each implementation to reflect
the current status of the system.  A configuration audit in RAMP
must be conducted by a VSA.
3.7 RAMP AUDIT



The RAMP audit process addresses both security analysis and configuration
management procedures.  The two components of a RAMP audit are
a configuration audit as described above and a detailed review
of security analysis records for a selection of product changes.
 The security analysis component involves drawing a random sample
of past Service Improvement Requests (SIRs, as described in Section
4) and assessing all the security analysis activities undertaken
to meet each request.  The objective is to confirm in each case
both the adequacy of the analysis and the completeness of the
stored records.


As already indicated, the RAMP audit is part of the functional
testing requirement for a product in RAMP, and the results of
the initial audit are reviewed by the Center evaluation team during
the product evaluation.  This review ensures that the vendor's
RAMP process follows the procedures outlined in the vendor's RM-Plan.
 A vendor's audit program is established clearly in the RM-Plan.
 The plan describes the frequency of audits and the procedures
for assessing configuration management and security analysis practices.
 The results of all subsequent RAMP audits are reviewed by the
Center's TPOC.  (See Section 7.)
4. PROCEDURAL ASPECTS OF RAMP

4.1 INTRODUCTION



RAMP uses strong procedural controls to assure that rating maintenance
actions by vendors do not compromise the product trust established
in Center evaluations.  On the other hand, overly rigid requirements
would be costly and inefficient for some vendors and thus could
limit program involvement.  The Center reconciles these concerns
in RAMP by allowing considerable vendor discretion in the design
of configuration management procedures, but requiring meticulous
adherence to plans once developed.


Rating maintenance procedures are described here using a generic
business model.  The Center developed this generic model by interviewing
numerous vendors and identifying common elements in their business
practices.  Discussing RAMP in this context serves to:

 • 1) provide a specific illustration of acceptable procedures;







2) establish common names for certain activities and functions;


3) clarify the elements essential for RAMP; and


4) provide a baseline against which alternative approaches can
be evaluated.

 • The discussion does not imply that each vendor's product revision
process must conform to the generic model.  What RAMP requires
is that the chosen procedures be no less effective than the generic
model in maintaining continuity of assurance and providing evidence
of product trust.






 • The following text assigns standard names to various procedural
elements and functions (summarized in the glossary).  This does
not imply that a vendor must create new entities corresponding
to the names, if equivalents already exist.  The Center requests
vendors to utilize the standard names in their RM-Plans and other
formal communications as an assistance to the Center in dealing
with diverse products and business plans.  Vendors should feel
no need to alter their internal language, since the VSAs interacting
with the Center can readily translate the few terms at issue.





4.2 GENERIC MODEL



Figure 3 depicts the generic model of rating maintenance actions
in RAMP.  The diagram emphasizes configuration control, although
configuration identification, accounting, and auditing tasks are
no less important.  All of the boxes and arrows represent configuration
management procedures identified in the Center survey of business
practices prior to RAMP.  The diagram has been converted to a
RAMP description by highlighting two control and approval functions
(using dotted lines and decision nodes), and by including commentary
on the VSA role.


The generic model can be summarized as follows, ignoring momentarily
the elements specific to RAMP.  Proposed system changes are drawn
from a prioritized list of desirable system modifications as described
in Section 1.  Requests for changes reach the system design group
through some mechanism that we call a Service Improvement Request
(SIR).  Each proposed change receives a preliminary screening
for effects on the TCB.  A change that clearly does not affect
the TCB directly or indirectly enters a design analysis phase
addressing product characteristics other than security.  (Code-level
design of the change may occur in varying proportions at this
stage and at the implementation stage.)  The design analysis ends
with some form of review.  A change that affects the TCB, or may
affect the TCB, undergoes security analysis in conjunction with
design analysis.


The analysis and review tasks yield an Engineering Change Order
(ECO), which directs the implementation of an approved change.
 The ECO covers modifications of tests and documentation as well
as the system software.  Code is written for the change and entered
into a working copy of the system for testing.  Existing and modified
tests are applied as appropriate.  The change is then subjected
to a final review.  Any change that fails to gain acceptance in
this final review is removed from the system.  If rejection has
been caused by an implementation problem, the change may recycle
back to the ECO stage.  Other changes rejected in the design review
or final review are sent back to the beginning of the configuration
management process or discarded altogether.  Implemented changes
that gain final approval are incorporated into the product, and
all documentation is updated accordingly.
4.3 ORIGIN OF PRODUCT CHANGES



This and the following subsections describe the requirements of
RAMP in the context of the generic model.  For convenience, the
text often references the VSA role as if played by a single person
even though multiple VSAs are likely.


The system revision process in RAMP starts with an evaluated product
(although the first changes may occur while the evaluation is
still in progress, or even before the code freeze for the evaluated
product).  The full configuration management process should be
operative as soon as a system is identified, so that all changes
relative to the original product can be managed uniformly.


The vendor selects changes from the prioritized list of desirable
system modifications established during the product development.
 Financial and marketing factors affect the choice of changes,
since these factors influence the revision cycle and the feasible
number of modifications per cycle.  RAMP requires some equivalent
of the Service Improvement Request (SIR) to provide a formal record
of all proposed changes entering the analysis and implementation
process.
4.4 CONFIGURATION CONTROL BOARD



All analytical and design tasks in RAMP should be conducted under
the direction of a corporate entity called the Configuration Control
Board (CCB).  The upper dashed line in Figure 3 encompasses the
activities in the generic model that the CCB should supervise.
 These include:  1)  screening of proposed changes for impact
on the TCB;  2)  security analysis of changes that affect the
TCB; 3) associated design analysis and review tasks; 4) approval
and disapproval  of  changes on  the basis  of product  trust;
 and 5)  issuance of instructions for change implementation (ECOs).


Central direction by a CCB does not necessarily mean that a vendor
must discard other ways of administering configuration management
in order to participate in RAMP.  The vendor can base the CCB
on an existing design supervision group, perhaps joined by other
persons when it sits as the CCB, or the vendor can establish the
CCB as a forum of representatives from multiple groups involved
in product development.


The membership of the CCB must include at all times a Center-recognized
VSA for the given product.  Furthermore, the responsible corporate
officer must have the power to veto any CCB approval of a product
change.  This veto power can derive from inclusion of the responsible
corporate officer as a CCB member with special voting rights;
from some other explicit provision of the CCB rules, or from the
authority vested in the responsible corporate officer by his or
her corporate position.  The responsible corporate officer is
not required to participate in CCB deliberations or decision-making
on a routine basis.  This arrangement gives the VSA two ways of
influencing product changes (over and above contributing to analysis
and design tasks).  The VSA can influence changes by participating
as a full member in the CCB function, and also by notifying the
responsible corporate officer that a given change approved by
the CCB is unacceptable in terms of RAMP assurance.  In essence,
the VSA represents security concerns to the CCB, and the responsible
corporate officer enforces the dominance of these concerns.  The
Center holds the vendor accountable for change control through
the responsible corporate officer.


RAMP requirements for the CCB are summarized as follows:

 • 1) The CCB operates at all times in accordance with the vendor's
RM-Plan.







2) No product change can be implemented without approval by the
CCB.


3) The CCB has authority over all analysis, design, and review
tasks from the receipt of SIRs through the issuance of ECOs.


4) The CCB has access to all information used in, and generated
by, the activities under its purview.


5) The VSA (or a VSA) is a CCB member with all of the rights,
powers, and information access possessed by other members.


6) The responsible corporate officer has the power to veto any
CCB approval of a product change.  Changes vetoed by the responsible
corporate officer are disposed in the same fashion as changes
disapproved by the CCB.

 • There are no restrictions upon CCB procedures for reaching
decisions, but the Center encourages using the CCB as a forum
for deliberations that can be recorded as RAMP evidence.  The
CCB ideally functions as a central source of "security wisdom"
as well as program oversight.





4.5 COMPLIANCE WITH  THE TCSEC AND CRITERIA INTERPRETATIONS




The preliminary screening of proposed changes for effects on the
TCB is an optional feature of the generic model, although some
arrangement of this nature is probably necessary for efficiency.
 A nonoptional feature of the model is that the changes that bypass
preliminary screening are routed through the subsequent phases
of the change control process (i.e., EACH CHANGE MODEL MUST CONTAIN
SOME TYPE OF CONFIGURATION REVIEW).  Retention of these changes
in the process allows the reviews by the CCB and Configuration
Review Board (CRB) to verify the absence of any direct or indirect
effects on the TCB.


Section 3 has already described the scope and responsibilities
of security analysis.  This task must determine that a proposed
change upholds the security features and assurances of the product
in compliance with the TCSEC and the Criteria interpretations.
 The outcome for each change is evidence that links with product
evidence from the evaluation.  Security analysis may require intensive
problem-solving efforts in establishing TCB effects, designing
changes, and developing appropriate tests.  The fundamental requirement
of RAMP is dominance of security over other design considerations.


The Center periodically issues Criteria interpretations to clarify
the application of the TCSEC.  An important issue in RAMP is the
time that is allowed to elapse between the issuance of an interpretation
and the compliance of a product release (and all subsequent releases)
with this interpretation.  The reasonable maximum time is related
to the length of a product's revision cycle (e.g., three months,
six months), but it cannot be linked rigidly to the revision cycle
without creating excessive difficulties for fast-cycling products
and excessive slack for slow-cycling products.  The Center recommendation
is that each product release in RAMP should comply with all Criteria
interpretations for which at least one of the following conditions
is true:

 • 1) The interpretation was issued prior to the EPL listing
for the previous release of the given product.







2) The interpretation was issued at least one calendar year prior
to the submission of a Rating Maintenance Report (RMR) for the
release in question.


3) The interpretation is accompanied by an effective date, which
precedes the RMR submission date for the release in question.


This policy would give vendors a grace period of one revision
cycle within which to comply with an interpretation, unless the
revision cycle is longer than one year or unless the interpretation
has an effective date that overrides the grace period.  The Center
cites an effective date if rapid compliance with an interpretation
is considered especially critical.  Each vendor proposes a policy
for complying with Criteria interpretations when submitting an
RM-Plan for Center approval.  (See Section 7.)  The approved policy
becomes a plan element that must be followed rigorously throughout
the RAMP process.


The need to comply with interpretations issued after the product
evaluation can mandate design analysis and even product changes
that have nothing to do with service improvements desired by the
vendor.  It is unlikely but possible that an interpretation will
terminate rating maintenance for a product and necessitate a reevaluation.
 Because the interpretations issued during one revision cycle
for a product typically do not apply until the next cycle, the
Center can usually indicate in advance whether or not a given
interpretation will affect the continued use of RAMP.  The VSA
has responsibility, however, for keeping abreast of interpretations
and assessing their impacts on the product.  Criteria interpretations
do not apply retroactively, so that product ratings established
through RAMP are not withdrawn because of subsequent interpretations.

4.6 ENGINEERING CHANGE ORDERS



An approved system change is implemented through an ECO or a set
of ECOs.  An ECO tells the maintenance establishment what must
be done to the code, the documentation, and other elements of
the system to implement the change.  The generic model shown in
Figure 3 assumes that an ECO contains instructions in relatively
high-level language, but code-level directives are also possible.
 Vendors can determine the format and content of ECOs subject
to the following general requirements.  In the generic model:

 • 1) The ECO provides an orderly mechanism to propagate change
across the system and assure synchronization, connectivity, and
continuity of alterations.







2) The preparation of ECOs is under CCB control.


3) No system change of any kind can occur without direction by
an ECO.


4) Each ECO retains the identities of the initiating SIR and any
other SIRs or ECOs occasioned by the initiating SIR.


5) ECOs are retained as evidence for rating maintenance and should
have a form suitable for record-keeping purposes.


RAMP assigns considerable importance to the ECO as part of the
trail of product evidence.  The vendor should establish the granularity
of ECOs so that they provide convenient reporting units throughout
rating maintenance.  As discussed in Section 6, the RMR describes
system changes at the ECO level.
4.7 IMPLEMENTATION, TESTING, AND FINAL REVIEW



The lower portion of Figure 3 describes the general process of
implementing and testing a system change.  The tests must verify
that the implemented change preserves the function of security
features and the assurance of correct feature operation.  Testing
and test development should be conducted independently from the
implementation of changes as a check on the latter process.  (Separation
of functions as practiced by accountants can provide a useful
safeguard in other areas of rating maintenance as well, subject
to RAMP requirements for overall coordination and control.)  The
reference to testing in Figure 3 covers both functional security
tests and performance tests, but only security tests contribute
to RAMP evidence.


The results of implementing and testing each change are assembled
for a final review before the change is incorporated into the
product.  An entity called the Configuration Review Board (CRB)
carries out this review.   The CRB membership should include a
Center-recognized VSA (not necessarily the same VSA belonging
to the CCB).  The VSA should have all of the information access
and influence over CRB decisions possessed by any other CRB member.
 The CRB can have the same overall membership as the CCB or can
be an independent quality assurance group.


The final review by the CRB provides closure on each ECO by verifying
that every aspect of the approved change was implemented correctly
and that no other alterations were made.  There should also be
a reassessment of test results and system assurances to confirm
that system trust has been upheld.  The CRB then decides whether
or not to accept a given change as part of the product.  Rejected
changes are removed from the system and disposed in the manner
discussed above.  The process ends for an accepted change with
final incorporation and documentation tasks.
4.8 COLLECTION OF RAMP EVIDENCE



General suggestions of configuration accounting and auditing have
 been indicated in the previous section.  The configuration management
system should include numerous checks to assure that all relevant
information is recorded and that documentation is updated fully
to reflect each product change.  As the custodian of RAMP evidence,
the VSA must remain in close touch with all documentation tasks
and should be able to influence the execution of these tasks.


A vendor with a functioning configuration management system prior
to RAMP may choose to record some RAMP evidence externally in
order to avoid overloading the system.  For each product change,
RAMP evidence will include the following commentary:  the SIR
from which the change originated; the procedures and arguments
used in establishing TCB effects; the issues and conclusions of
the security analysis; the ECOs generated for the change; and
the completion status of ECOs.  The vendor must be able to perform
line-by-line code comparisons with pointers back to the ECOs causing
specific modifications.  The commentary on tests should include
descriptions of new and modified tests, with stated reasons for
the alterations and pointers to the test results.
4.9 VSA ROLE



The required duties of a VSA are suggested by the items on the
right-hand side of Figure 3.  The VSA is the focus of security
wisdom in RAMP.  The VSA (or VSAs) tracks the entire rating maintenance
process and understands product changes in sufficient depth to
verify the adequacy of security analysis and configuration control
procedures.  The VSA represents the Center concerns to the CCB
and CRB, and assures that these functions are operating effectively
to maintain product trust.


The VSA is custodian of all RAMP evidence, meaning that the VSA
monitors the accumulation of evidence and has sufficient resources
to assure its accuracy, completeness, and accessibility.  The
VSA has direct responsibility for proposing and managing revisions
to the RM-Plan.  The VSA performs or supervises the RAMP audit
function and the preparation of all materials for submission to
the Center.  Lastly, the VSA is the vendor contact for all technical
communication with the Center.


Section 2 has addressed the subjects of VSA training, VSA recognition
by the Center, establishment of VSA credibility, and multiple-VSA
approaches.  At least one Center-recognized VSA must be representing
the product at any time that rating maintenance actions are underway.
 A vendor using multiple VSAs must designate a lead VSA and must
maintain an accurate description of VSA responsibilities in the
RM-Plan at all times.  Communications between VSAs and the Center
are discussed in the next section.


PROGRAM REVIEWS, COORDINATION, AND ADMINISTRATION
5. PROGRAM REVIEWS, COORDINATION, AND ADMINISTRATION

5.1 PROGRAM REVIEWS



Two types of program review occur during the RAMP cycle between
submissions of product evidence.  An interim review takes place
following each vendor RAMP audit.  Aperiodic reviews occur irregularly
throughout an application of RAMP on an average of less than one
review per cycle.  An aperiodic review is always conducted by
a Center review team at the vendor's site (or multiple sites if
applicable).  Interim reviews may or may not occur on-site.  As
noted in Section 1,  the first interim review for a product in
RAMP occurs following the vendor's RAMP audit performed in preparation
for the product testing TRB session.


Both types of review have the general purpose of establishing
VSA credibility and confirming process assurance in RAMP.  The
reviews serve the common interest of vendors and the Center in
identifying problems as early as possible so that the vendor can
make corrections with minimum impact upon rating maintenance and
product evolution.


Review teams examine the evidence accumulation process and scrutinize
records such as SIRs, ECOs, test results, and reports on CCB and
CRB proceedings.  VSAs are questioned about RAMP procedures and
may be required to trace the course of events for specific product
changes.  The vendor must have the ability to perform a line-by-line
code comparison for any two points in time and to sustain a RAMP
audit by a Center review team.  Program reviews are also an occasion
for assessing the adequacy of the vendor's RM-Plan, and may lead
to RM-Plan modifications.
5.2 INTERIM REVIEWS



Interim reviews and aperiodic reviews differ somewhat in emphasis.


An interim review has a procedural focus, addressing the credibility
of the configuration management process and its adherence to the
RM-Plan.  An aperiodic review covers much of the same ground but
includes an in-depth examination of the vendor's ability to conduct
security analysis.


The subjects of investigation include the procedures for generating
SIRs and ECOs, the adherence to established security analysis
and design analysis policies, the exercise of central control
by the CCB, the effectiveness of the CCB and CRB review functions,
the adequacy of test development and documentation procedures,
and all aspects of the configuration accounting system.  The interim
review team verifies that all product changes are controlled uniformly,
that security concerns have precedence over other development
objectives, and that sufficient evidence is accumulating to support
process assurance.


Interim reviews focus strongly upon the credibility of each VSA
as a representative of the vendor's RAMP process.  The first interim
review for a VSA is a critical milestone in the establishment
of VSA credibility.  All VSAs demonstrate to the interim review
team a broad knowledge of security-related policies, issues, and
practices for the given product, and an ability to apply the TCSEC
in concrete situations.  The interim review verifies that the
VSA (or group of VSAs) is tracking every aspect of the configuration
management process and is participating sufficiently in each task
to understand the major issues and decisions for every product
change.
5.3 APERIODIC REVIEWS



An aperiodic review constitutes an assurance checkpoint in a vendor's
RAMP program.  Vendors receive no information about the timing
of aperiodic reviews other than sufficient advance notice to allow
an orderly review process (i.e., a few days).  Vendors designate
one point of contact per RAMP activity site to be notified in
case of an aperiodic review.


An aperiodic review examines in detail the soundness of a vendor's
decisions and the adequacy of product evidence to support the
assertions of product trust contained in Rating Maintenance Reports
and other VSA statements.  An objective in some cases is to determine
the reasons for problems already identified.  The review team
may select several recent product changes and trace the entire
sequence of events leading to the implementation of each, with
particular emphasis upon the thoroughness and accuracy of security
analysis.  This process examines the vendor's analytical competence
and sensitivity to security issues as well as the effectiveness
of configuration control and configuration accounting procedures.


The aperiodic review team looks for trust violations consisting
of: insufficient understanding and application of computer security
principles; failure to give top priority to security concerns;
errors in security analysis and product testing; failure to follow
the RM-Plan; and failure to report all relevant actions and circumstances
as product evidence.  If an aperiodic review identifies a security
flaw in the product or a breakdown of process assurance, the Center
reserves the option of withdrawing EPL status from the affected
version of the product and all subsequent versions.  (See Section
8.)
5.4 PROGRAM COMMUNICATION AND COORDINATION



There is a designated Center Technical Point of Contact (TPOC)
for each product in RAMP.  The TPOC tracks the rating maintenance
process from the planning phase onward and coordinates all technical
interchange between the vendor and the Center.  The TPOC is the
vendor's entry into the Center for the resolution of computer
security issues and concerns.  The TPOC assesses VSA performance
and other aspects of the program, particularly during the first
RAMP cycle but does not directly supervise vendor activities.


There is also a Center Business Point of Contact (BPOC).  The
BPOC carries out administrative functions in RAMP such as: making
programmatic decisions; planning the use of Center resources;
providing a conduit for official documentation; and notifying
the vendor of rating determinations.


Section 2 has discussed the general duties and responsibilities
of the vendor's responsible corporate officer.  The responsible
corporate officer administers the RAMP program and is the vendor's
point of accountability to the Center.  The responsible corporate
officer is a person empowered to make financial commitments on
behalf of the program; maintain a favorable corporate context
for its execution; and limit product changes as necessary for
protection of RAMP assurance.  The responsible corporate officer
assumes full responsibility for the contents of each Rating Maintenance
Report.


Figure 4 shows the lines of communication in RAMP between the
TPOC, BPOC, responsible corporate officer and VSA(s).  All interactions
on administrative matters are routed between the BPOC and the
responsible corporate officer.  All technical communication passes
through the TPOC, with two exceptions.  These exceptions are on-site
reviews and VSA interactions with the TRB when defending an RMR.


The Center requires the vendor to designate a lead VSA in multiple-VSA
situations primarily to facilitate orderly communications.  The
lead VSA should conduct most technical interactions with the Center
(possibly excluding on-site reviews and RMR presentations), and
should receive copies of any written documents passing between
the vendor and the Center.  In some cases the TPOC may require
that all technical communication be routed through the lead VSA.


The lead VSA will provide quarterly, informal status reports to
the TPOC (via the Dockmaster system mentioned below).  These reports
are intended to keep the Center apprised of the vendor's rating
maintenance activities.


The Center discourages excessive vendor reliance upon the TPOC
as a program advisor.  The TPOC apprises the vendor of important
developments in the computer security field and is available for
consultation on major issues.  This does not relieve the vendor
of responsibility for keeping abreast of developments through
other means (such as the Dockmaster system mentioned below) and
exercising security wisdom independently of the Center.  Vendors
are discouraged from attempting to pass program responsibility
back to the Center by submitting routine decisions to the TPOC.
 The success of RAMP depends upon a vendor's own security analysis
capability and willingness to be held accountable for actions
affecting the product.


All vendors participating in RAMP must provide for VSA access
to the Center's Dockmaster information system by the time VSA
training begins.  Dockmaster is a Honeywell MULTICS system used
by the evaluation community for electronic mail, electronic meetings,
forums, queries, and other functions.  A RAMP vendor must be prepared
to communicate with the TPOC via Dockmaster and to use the system
as a general information source.
6. PRESENTATION AND REVIEW OF EVIDENCE

6.1 INTRODUCTION



A vendor in RAMP preserves security features and assurances of
a product through security analysis and configuration management.
 The documentation of this process in a body of evidence linking
to the evaluation yields RAMP assurance of product trust.  Because
the process is subject to strong procedural controls*the RM-Plan,
on-site reviews, and VSA training*the Center can extend the product
rating to each new release without performing a full reevaluation
or a lengthy assessment of all product evidence.  Rating approvals
are based upon a moderately detailed summary of evidence and a
face-to-face presentation of this material by the vendor to the
Center.  The Center reserves the right to request additional evidence
as necessary.


The vendor prepares the summary of evidence in the form of a Rating
Maintenance Report (RMR).  The vendor can submit the RMR to the
Center at any time after all changes have ended for the product
version in question.  Delays can be minimized by preparing much
of the RMR while the product is being revised, i.e., by summarizing
the evidence as it accumulates.


The following are the major steps leading to a rating approval
and EPL listing for a revised product.  These steps are discussed
at greater length following the description of the RMR.

 • 1) Vendor submits RMR and other materials to TPOC.







2) TPOC circulates RMR to Center evaluators for review.


3) TPOC forwards RMR and supporting materials to Technical Review
Board (TRB).


4) TRB reviews RMR and issues comments to vendor (through TPOC).


5) VSA or VSAs defend RMR before TRB.


6) TRB makes recommendations on rating maintenance to Chief of
Center Product Evaluation Division.


7) Chief of Product Evaluation Division approves or disapproves
product rating.


8) Revised approved product receives EPL listing.


Steps 1 and 2 may iterate until the TPOC is satisfied with the
level of detail of the RMR.  Only a short time should elapse between
steps 3 and 8 if the vendor has properly satisfied the RAMP requirements
(summarized in Appendix A) and has a well-executed RAMP process
(defined by the vendor's RM-Plan) with adequate VSA credibility.
 Thus, efficient preparation of the RMR and supporting materials
can lead to an EPL listing at roughly the same time that the new
product version is released.
6.2 RATING MAINTENANCE REPORT



The RMR summarizes product evidence at a level of detail intermediate
between the information that would be required to conduct an evaluation
and the information typically contained in a Final Evaluation
Report.  The RMR asserts that product trust has been upheld and
includes sufficient commentary to allow an understanding of individual
product changes.  Figure 5 presents a suggested outline for an
RMR.  The Center does not impose a standard format on these documents
but requires coverage of all the listed items.


The major components are a cover letter, a description of the
system configuration, a section on Criteria interpretations, a
discussion of each product change at the ECO level, and a future
change analysis.  The cover letter identifies the product and
describes its history of rating maintenance.  The cover letter
must be signed by the responsible corporate officer and all recognized
VSAs.  It affirms that the responsible corporate officer:  1)
has reviewed the RMR; 2) assumes full responsibility for the RMR
contents; and 3) acknowledges responsibility for the sincere and
conscientious execution of all rating maintenance actions.


The first report section gives a complete overview of the system
configuration and its changes since the product evaluation.  Much
of this material can often be carried forward from earlier documents.
 General discussion of RAMP policies and procedures can appear
either here or in a separate section.  The second section discusses
the significance of all Criteria interpretations applying to the
given product release.  (The vendor's policy with regard to interpretations
is discussed in Section 4 and Section 7.)


The items in the third section of the suggested RMR outline are
repeated for each product change.  RAMP defines an individual
change in this context as an Engineering Change Order (ECO) that
has been implemented.  Figure 5 assumes a classification of ECOs
according to product module and configuration item.  (The classification
may vary if ECOs overlap configuration items.)  Discussions can
be pooled and cross-referenced in cases where several ECOs have
been used to achieve a common purpose, but the RMR should list
each ECO individually.


The last lines in the third section of the RMR outline suggest
the topics requiring mention in the evidence summary for an ECO
affecting the TCB.  Very little discussion is necessary for other
ECOs*one or two sentences as compared with at least a paragraph
for each ECO having TCB impact.  (These two categories of ECOs
may be segregated in the RMR.)  The appropriate depth of discussion
for an ECO affecting the TCB depends upon the sensitivity of relevant
security mechanisms and assurances and upon the complexity of
the security analysis.


The fourth section of the RMR as outlined in Figure 5 is a discussion
of probable changes in the product beyond the current version.
 The Center uses this future change analysis to assess the future
applicability of RAMP to the product (as discussed below).  The
Center requests vendors to describe the major product changes
anticipated for the next two release cycles or the next 18 months,
whichever period is greater.  A failure to provide this information
increases the vendor's risk of discovering suddenly that RAMP
is no longer feasible and the product is no longer eligible to
participate in RAMP.   In order to be placed on the EPL, the product
must then be reevaluated.


Figure 5.  Suggested Rating Maintenance Report Outline
COVER LETTER



Identification of the new product version, the evaluated product,
and any intervening product releases.


Identification of the product rating established in the evaluation
and maintained through the previous release.


Serial numbers of the Final Evaluation Report (FER), any revised
versions of the FER, and the RMR for the most recently maintained
release. Assertion that the new release maintains the product
rating. Responsible corporate officer warranty of document contents.


Signatures of the responsible corporate officer and all Center-recognized
VSAs.
SECTION 1:  SYSTEM CONFIGURATION



Listing of the hardware/software configuration for the


evaluated product


(original TCB by module).


Rationale for system decomposition into configuration items. Updated
listing of the configuration, noting changes: List of hardware
contained in the secure configuration. List of TCB software modules,
noting any modules that have been changed and the file length
(lines of code) of each module. Rationale for determining effects
on the TCB of product changes, with pointers to specific changes
itemized in Section 3.
SECTION 2: CRITERIA INTERPRETATIONS



List of all Criteria interpretations applying to this product
 release.


Comments on the significance of each interpretation for the product
as revised.


Pointers to discussions in Section 3 of product changes


made because of specific Criteria interpretations.
SECTION 3:  PRODUCT CHANGES AND EVIDENCE OF SYSTEM TRUST



Name of module or document changed.


ID number(s) of configuration item(s) changed.


Engineering Change Order (ECO) number.


Description of change:


Functional description.


Description of user-visible effects.


Classification of change according to effects on the TCB (yes
or no).


Evidence of product trust (if change affects the TCB):


Explanation of relevant Criteria and interpretations.


Relevant TCB mechanisms and assurances. Design issues, alternatives,
and solutions. Tests and test modifications if any. Summary of
test results. Pointers to system and test documentation. Pointers
to specific code-level changes.
SECTION 4:  FUTURE CHANGE ANALYSIS



Expected product changes in next revision cycle.


Expected product changes in second revision cycle.


Later evolution of product.]
6.3 OTHER SUBMISSION MATERIALS



The materials submitted concurrently by the vendor to achieve
rating maintenance include several items in addition to the RMR.
 The overall package is as follows.

 •  RATING MAINTENANCE REPORT (RMR)
 •
 •  RM-PLAN(S) WITH CHANGE BARS
 •
 •  FINAL EVALUATION REPORT (FER) WITH CHANGE BARS
 •
 •  FINAL EVALUATION REPORT WITH INTEGRATED CHANGES
 •
 •  PROPOSED PRODUCT DESCRIPTION FOR EPL
 •




As discussed elsewhere, RM-Plans often change during a rating
maintenance cycle because of procedural refinements and changes
in VSA responsibilities.  The Center is always aware of changes
and always possesses a current version of the RM-Plan, because
changes cannot be effected without Center approval.  The vendor's
submission package at the end of a rating maintenance cycle includes
an additional copy of the RM-Plan with change bars showing every
alteration relative to the plan that was in force at the end of
the previous cycle (i.e., when the previous RMR was submitted).
 This document must show the date on which each RM-Plan change
was approved by the Center.  Its purpose is to assist review of
the vendor's program by the TRB.  (A general principle of the
rating approval process is that the vendor should not assume a
TRB "memory.")  The vendor may also choose to include
a separate document consisting of a proposed RM-Plan for the next
revision cycle.  Submitting proposed RM-Plan changes at this time
facilitates Center approval and serves the Center objective of
confining most plan alterations to the beginning of a cycle.


The submission package includes a copy of the Final Evaluation
Report (FER) for the initial evaluated product, with change bars
converting the FER to a description of the current release.  The
vendor also provides a copy of the FER with these changes integrated
into the text.  The latter document is called a RAMP FER to distinguish
it from the direct output of a Center evaluation.


The remaining document submitted with the RMR is a brief description
of the revised product for use by the Center in publishing an
EPL listing if the new version maintains the product rating.
This and the RAMP FER are the only program documents intended
for public release.
6.4 REVIEW AND DEFENSE OF RMR



The TPOC receives the RMR and associated materials from the vendor
and forwards these documents to Center evaluators for review.
 A primary objective is to prepare the VSAs for examination by
the TRB.  The reviewers point out areas of the RMR that are deficient
or likely to receive special TRB attention.  The VSAs respond
by revising the RMR and/or assembling supplementary evidence for
the product defense.  The TPOC then submits the RMR and related
materials to the TRB.  After examining the RMR, the TRB may transmit
written comments to the VSAs (through the TPOC), which establish
a partial agenda for the VSAs' oral presentation and defense.


All Center-recognized VSAs should be prepared to meet face-to-face
with the TRB and discuss the aspects of RAMP for which they have
been responsible.  The TRB will expect the VSAs to present a thorough
technical overview of changes to the product TCB and the security
analysis of those changes, thus demonstrating continuity of function
and retention of assurance.  When new VSAs are involved, the face-to-face
examination is strongly concerned with establishing VSA credibility.
 The TRB questions each new VSA in depth about the nature of the
product as well as about rating maintenance procedures and individual
changes.


The TRB will focus upon changes which raise complex security questions,
or which are not fully understandable from the RMR description,
or which provide a good context for detailed examination of procedures.
 The responsible VSA first describes the change and answers questions
on the basis of memory and supplementary information brought to
the session.  If these responses are inadequate, the TRB requests
additional evidence.


The TRB subsequently issues a recommendation to the Chief of the
Product Evaluation Division stating that product trust has or
has not been maintained by the current product version at the
level established by evaluation.  If the product does not sustain
its rating, the vendor may or may not be given the option of reconstructing
the RAMP process in some fashion and returning for another TRB
review.  The given RAMP cycle ends with a rating determination
by the Chief of the Product Evaluation Division and, if the determination
is favorable, a listing of the new release in the EPL.
6.5 FUTURE APPLICABILITY OF RAMP



RAMP applicability is limited.  If product revisions fundamentally
alter security mechanisms and assurances, the result from a security
standpoint is a new product requiring evaluation to qualify as
a trusted system.  At the start of RAMP, the Center verifies the
potential applicability of the program to the initial revisions
of the product before approving the vendor's RM-Plan.  The RMR
review at the end of each cycle is the occasion for later forecasts
of RAMP applicability.  These forecasts of future RAMP applicability
are an integral part of the trusted products partnership established
between the Center and the vendor.


The Center uses the information in the vendor's future change
analysis to estimate (if possible) the point at which RAMP will
no longer be viable and the product cannot be placed on the EPL
without a reevaluation.  This point can result from cumulative
changes as well as from especially significant changes in any
one revision cycle.  The Center criteria for RAMP applicability
cannot be summarized conveniently here.  The extremes are that
most changes in system architecture are not coverable by RAMP,
whereas product changes that do not affect the identified TCB
directly or indirectly can always be covered.


The Center has designed RAMP with the intention of giving vendors
at least one cycle's advance notice of the need for a product
reevaluation.  (Hence the request for information in the future
change analysis describing at least two cycles.)  The degree of
certainty expressible by a RAMP forecast is governed, in large
measure, by the level of detail, completeness, and the schedule
provided in the future change analysis by the vendor.  Notifying
the vendor that RAMP can proceed for another revision cycle does
not commit the Center to approve rating maintenance for that cycle
when completed, and a forecast of RAMP applicability for a later
cycle may be changed as that cycle approaches.  The Center reserves
the right to deny a rating and/or discontinue a RAMP process at
any time.


When forecasting RAMP applicability for a product, the Center
addresses any expected difficulty in complying with recent or
prospective Criteria interpretations that do not apply to the
current product version.


As discussed in Section 4, Criteria interpretations can affect
the use of RAMP irrespective of the nature of product changes.
7. RATING MAINTENANCE PLAN

7.1 INTRODUCTION



Strict adherence to a comprehensive RM-Plan is one of the most
important program controls in RAMP.  The RM-Plan is the vendor's
document, tailored to the product in question and to the company's
business practices and personnel.  The plan and any proposed changes
must be approved by the Center and must describe accurately throughout
product maintenance what the vendor is doing to the product and
what evidence is being recorded.


A vendor starting a new RAMP process should commence preparation
of an RM-Plan during or immediately after VSA training.  No rating
maintenance actions on the product can occur until an approved
RM-Plan is in place, which means that delays in program planning
can slow the startup of product revisions.  Vendors should develop
a new RM-Plan by building upon rather than rejecting previous
practices.  The Center encourages this approach in order to minimize
the chances of conflict and inefficiency in RAMP.  Also, the vendor
should not attempt to resolve every issue and establish an ideal
plan before submitting a draft to the Center for review.  A period
of consultation between the vendor and the Center is usually necessary
to arrive at a mutually acceptable RM-Plan.  In plan development
as in later phases of RAMP, the Center is eager to help vendors
who approach the process constructively.


A vendor initiates the RM-Plan approval process by submitting
a new or revised plan to the TPOC.  The TPOC coordinates the Center
review and issues an approval when the plan is judged to comply
with RAMP requirements.  The TPOC will document approvals of new
or revised RM-Plans and changes to existing plans via the Center's
Dockmaster system.


A vendor may wish to change an existing RM-Plan in order to improve
the rating maintenance process or alter VSA responsibilities.
 There are no fixed limitations on changing an RM-Plan, but the
Center urges vendors to minimize the total number of changes and
to confine change requests to the beginning of each rating maintenance
cycle.  A change request includes a copy of relevant sections
of the RM-Plan with all proposed changes shown by change bars,
plus a copy of the entire plan with the changes integrated into
the text.  The latter becomes the operative RM-Plan when approval
is granted.


All RM-Plan changes must receive Center approval regardless of
their nature.  On receiving a change request, the TPOC determines
the scope of the Center review based upon the magnitude and implications
of the proposed change(s).  The TPOC can grant immediate approval
of a change that is very minor or unavoidable (such as a reassignment
of program responsibilities due to loss of a VSA).  In all cases,
however, the old RM-Plan remains in force until the change is
approved and documented on the Center's Dockmaster system.


RM-Plans are intended to be current but not release-specific.



This distinction becomes relevant when successive product releases
overlap in terms of development, i.e., when work starts on version
N+1 before the code freeze for version N.  In such cases, a single
RM-Plan describes the vendor's RAMP process for all work on the
product.  The RM-Plan may reference specific product versions
when describing VSA responsibilities, thus creating a need to
update the plan periodically; but this is similar to cases in
which VSA assignments are based upon specific product changes
or other transient factors.  The single-plan format applies unless
there is a branching of the product, i.e., a situation in which
version N includes changes that are not contained in version N+1,
as well as vice versa.  If the Center allows RAMP coverage of
both branches, the vendor must maintain a separate RM-Plan for
each.
7.2 OVERVIEW OF RM-PLAN CONTENTS



The RM-Plan tells how the vendor will accomplish all the tasks
and achieve all the results described previously in sections 3,
4, and 6.  The RM-Plan cannot state exhaustively how security
analysis will be conducted and cannot guarantee that errors will
never occur.  However, the plan describes the vendor's procedures
and safeguards in sufficient detail to constitute an essential
part of RAMP assurance.


While the format of individual RM-Plans may vary,  a vendor's
RM-Plan must address the following topics.  Each of these topics
is discussed in the subsections that follow.

 • A. The product and its configuration.







B. Security analysis.


C. Configuration control.


D. Collection and verification of evidence (configuration accounting
and RAMP auditing).


E. Compliance with Criteria interpretations.


F. Presentation and defense of security analysis and product evidence.


G. VSA responsibilities and program administration.


H. Vendor response to failures.


I. Numbering and retirement of product versions.


J. Management of the RM-Plan.
7.3 THE PRODUCT AND ITS CONFIGURATION



An RM-Plan must begin with a description of the rated product
and all its components.  This description should address all elements
of the TCB in specific terms.  It should also cover business aspects
of the product such as control over the distribution of documentation.


The RM-Plan describes how configuration identification has been
performed.  The plan should discuss the vendor's approach and
objectives in decomposing the system, and should describe system
elements in sufficient detail to show compliance with the configuration
identification requirements listed in Section 3.


There should be commentary on any special implications of the
system identification for configuration control.  The plan specifies
the naming conventions used for configuration items (CIs) and
for changes to CIs.  Policies regarding the creation of new CIs
for revised products should also be discussed.


A startup RM-Plan includes a development process timetable, indicating
when submissions of evidence are anticipated, and a future change
analysis discussing the expected evolution of the product.  As
in the RMR for a completed RAMP cycle, the future change analysis
should cover at least the first two cycles or 18 months of RAMP,
whichever is longer.  The Center assesses the expected changes
and expresses a judgment by way of the RM-Plan approval that the
product rating can probably be maintained through the initial
revisions.
7.4 SECURITY ANALYSIS



The RM-Plan states the vendor's policies and procedures for security
analysis in as much detail as possible.  It describes security
analysis and related design activity on a task-by-task basis,
from identifying TCB effects through developing new tests and
reporting on the acceptability of changes.  The plan should demonstrate
clearly that the vendor understands and adheres to the concept
of security dominance in product development.  This part of the
RM-Plan may or may not be integrated with discussion of the vendor's
configuration control system, which covers the overall structure
of change control and the participation of corporate groups in
this process.


The RM-Plan must describe the steps taken by the vendor in assessing
the effects of product changes on the TCB.  This description covers
methods of establishing indirect TCB effects as well as effects
due to interrelationships among security features.  The plan should
reference any generic procedures used such as regression testing.
 There should be clearly stated arrangements for identifying any
cumulative effects due to multiple product changes and/or collateral
modifications entailed by changes.  These arrangements are especially
critical when security analysis and system design tasks are spread
among several operating groups.


The RM-Plan then describes the principles and procedures followed
by the vendor in establishing acceptable designs for product changes
and determining when changes cannot be implemented for security
reasons.  If no single description of this process is adequate,
the plan can reference various categories of product changes and
show how the process operates for each.  There should be explicit
discussion of the relationships between security analysis and
the pursuit of other design objectives.


A section of the RM-Plan must address the development and application
of system tests as an element of security analysis.  This discussion
covers:  the vendor's general testing policies; the determination
of test adequacy as affected by product changes; the guidelines
followed when modifying or creating tests; and the vendor's procedures
for updating the test plan on the basis of security analysis findings.


The RM-Plan summarizes the vendor's criteria and methods for concluding
that a change is or is not acceptable under the TCSEC and describes
how these conclusions are documented and forwarded for Configuration
Control Board  (CCB) review.  The plan must demonstrate that the
security analysis yields adequate RAMP evidence in the form of
recorded analytical findings and support for all decisions affecting
the product.
7.5 CONFIGURATION CONTROL



As established in Section 3, configuration management is the framework
for reviewing, implementing, and documenting the conclusions of
security analysis.  The portion of the RM-Plan on configuration
control presents the vendor's business plan for accomplishing
these objectives.


A vendor developing a startup RM-Plan may find it convenient to
work incrementally from existing practices.  First, the vendor's
existing configuration management system is modeled and evaluated
against the conceptual requirements of RAMP discussed here in
Section 3.  The vendor revises the model by identifying needed
elements and finding the most harmonious ways of including these
elements within the present business context.  The vendor then
evaluates the revised model against the procedural requirements
and VSA responsibilities outlined in Section 4.  Functional equivalents
of the SIR, ECO, CCB, and CRB are identified.  If there is no
full equivalent for one of these entities*e.g., no central authority
that can be designated as the CCB*the vendor overcomes the deficiency
by building upon present functions with as little disruption as
possible.  Similarly, the vendor seeks to identify persons who
can serve effectively as VSAs in their present corporate positions
(and who are qualified and available for VSA training).  Only
if such persons are unavailable does the vendor consider restructuring
groups and reassigning personnel to achieve adequate VSA involvement.


The RM-Plan must present a unified discussion of configuration
control centering upon the vendor's business model as revised.
 The discussion should trace the course of events for a product
change from its entry into the RAMP process as a SIR through its
final approval and incorporation.


The plan should explain the preliminary screening of changes for
TCB effects, if conducted as a separate task, and describe the
vendor's safeguards against incorrect categorization of changes.
 The plan shows how product changes that lack TCB effects are
routed through the various design and implementation steps and
change reviews.  The RM-Plan then presents the detailed discussion
of security analysis for changes affecting the TCB, if this discussion
has not already been provided.  The vendor indicates which operating
groups conduct the security analysis and to what extent the VSA
or VSAs participate in each aspect.  (Coverage of the VSA role
by the RM-Plan is discussed further below.)


The RM-Plan should describe in specific terms how the CCB will
coordinate the security and design analyses and will review system
changes.  The discussion addresses the composition of the CCB,
the lines of authority among its members, the nature of its deliberations,
and the manner in which the CCB assures security dominance in
the product development process.  Other topics are the power of
the CCB to influence security analysis, the quality control steps
involved in CCB review, the ability of the CCB to request additional
information, and the disposition of product changes that fail
to receive CCB approval.  The RM-Plan should describe VSA membership
and participation in the CCB, and the ability of the responsible
corporate officer to veto a CCB approval when requested by the
VSA.


The RM-Plan should discuss the manner in which ECOs are generated
and what they contain.  The relevant data include:  who prepares
ECOs; the granularity of ECOs; the conditions under which multiple
ECOs are used to effect a given change; the level of detail at
which ECOs direct implementation tasks; the instructions in ECOs
for testing implemented changes; any quality control procedures
for ECOs; and the manner in which the CCB controls the production
of ECOs.  The RM-Plan should also indicate the role of ECOs in
the vendor's record-keeping system.


The RM-Plan describes the vendor's procedures for assuring that
all approved changes are implemented correctly and that only these
changes are made.  The plan should discuss the structure of the
implementation and testing groups, indicating the degree to which
the testing function is conducted independently.  The description
of testing procedures should mention interactions with the design
group (outside the ECO process) on the subjects of test adequacy,
test development, and test results.  The plan should also summarize
briefly the management of the system code, e.g., the use of working
copies to implement and test changes.


The RM-Plan must specify the nature and operation of the Configuration
Review Board (CRB) as described above for the CCB.  The plan then
discusses the final review process in terms of:  the information
delivered to the CRB on each implemented change; the quality control
procedures utilized by the CRB to assure that the implementation
is correct; the means of verifying that no system modifications
have occurred other than the approved change; and the CRB policies
for granting final approval or disapproval.  Any exceptions to
the review process should be noted.  The RM-Plan describes the
removal of disapproved changes from the product and the policies
for returning such changes to an earlier stage of assessment.


The RM-Plan must acknowledge any special limits upon configuration
control.  For example, if the vendor's product development activities
take place at more than one site, the RM-Plan states what aspects
of RAMP occur at each site and how central coordination is achieved.


RM-Plans for layered products must describe specifically how the
vendor will deal with the involvement of more than one company
in producing the product.  There is no compromise in the required
level of RAMP assurance to accommodate layered products.  The
vendor demonstrates full configuration management cognizance,
meaning that the vendor has evidence on the base product and its
evolution comparable to the evidence required by RAMP for an in-house
product.  The vendor's RM-Plan describes in detail how this evidence
is obtained, covering the nature of security analysis and the
existence of any cooperative arrangements among producers.
7.6 COLLECTION OF RAMP EVIDENCE



The RAMP process essentially yields three categories of product
evidence:  1) the findings of security analysis, with support
for all conclusions from that analysis; 2) the records from configuration
control of the design phase, from SIR receipt through CCB review
and ECO issuance; and 3) the configuration control records for
the implementation phase, covering test results, test documentation,
and verification of changes by the CRB.  Ideally, there should
be a unified configuration accounting system that embraces all
of this information.  Vendors entering RAMP may find, however,
that the first category of evidence overloads existing configuration
accounting systems because of the extensive commentary on security
analysis findings and decisions.  An acceptable solution is to
establish supplementary information files with clear linkages
to the configuration management data via pointers and cross-references.


The RM-Plan must include an overall description of the vendor's
record-keeping system, covering basic facts such as where the
master version of the code is stored and how it is protected from
unauthorized modification or use.  The discussion lists the major
database elements and notes any associated divisions of activity.
 (For example, the recording of information for system changes
might be distinguished from the management of system documentation,
tests, tools, test documentation, etc.)  The plan describes how
the vendor can determine the status of proposed and approved changes
and can locate any supporting information.


The RM-Plan then revisits the entire configuration control process
and states the documentation requirements associated with each
step (unless documentation has already been covered in the section
on configuration control).  There should be one or more reporting
tasks associated with almost every element of a rating maintenance
model such as shown earlier in Figure 3.  In each case, the RM-Plan
must describe:  what information is recorded; where it is recorded;
who is authorized to store and retrieve information; and what
steps are taken to assure that information is accurate and comprehensive.
 The plan also discusses the uses of this information in the configuration
control process for review and approval purposes.


The Center recognizes that there may be a time granularity below
which the system code, documentation, tests, and test documentation
cannot be maintained on a synchronous basis because of lags in
the updating process.  The RM-Plan should estimate the duration
of configuration accounting lags and describe any necessary steps
to avoid problems from this source.


The RM-Plan must address the RAMP audit function and the VSA role
in this function.  The plan must establish configuration audit
procedures for verifying compliance with every configuration control
and configuration accounting requirement, and for checking the
adequacy of all associated evidence.  The plan should describe
the security analysis portion of the RAMP audit in terms of:
the procedures for sampling SIRs; the number of SIRs investigated;
and the standards for assessing the adequacy of security analysis
and related documentation.  The RM-Plan should also state the
vendor's intended schedule of RAMP audits.  The Center does not
impose a uniform requirement in this regard because of the widely
varying circumstances encountered, with the exception that at
least one RAMP audit must occur per RAMP cycle.
7.7 COMPLIANCE WITH CRITERIA INTERPRETATIONS



The RM-Plan must explain in detail the vendor's policy for complying
with Criteria interpretations as they occur.  The Center's recommended
guidelines for such a policy have been discussed in Section 4.
 The objective is to provide the maximum compliance with interpretations
consistent with a vendor's unique ways of doing business.  Center
approval of the RM-Plan is contingent upon attaining this objective.
 The policy statement in the RM-Plan should refer to the product
revision cycle (i.e., the maximum number of cycles that can elapse
before compliance occurs) and should also include calendar time
as a factor if the revision schedule is variable.
7.8 PRESENTATION OF EVIDENCE



Section 6 has described the contents of the Rating Maintenance
Report (RMR) and other documents submitted by the vendor to the
Center at the end of each RAMP cycle.  The RM-Plan should discuss
briefly how these documents are prepared and how they will be
used to defend the product, the security analysis, and the configuration
management process before the TRB.


The new material in any given RMR consists primarily of the evidence
summaries for product changes.  (See Figure 5 in Section 6.)
The RM-Plan should describe the contents of these summaries for
product changes that do and do not affect the TCB.  The summarization
process should be discussed with reference to the extent of VSA
involvement, the configuration accounting files used, and the
vendor's ability to prepare evidence summaries while other product
changes are still under way.  The RM-Plan should estimate the
time delay between the end of product changes and the submission
of an RMR to the Center for review.


Regarding the defense of evidence, the RM-Plan should indicate
which VSA or VSAs will represent the product at the next evidence
submission and what provisions will exist for supplying evidence
not contained in the RMR.  Rough estimates should be given for
the number of hours or days needed to comply with various types
of information requests by the TRB.
7.9 VSA AND RESPONSIBLE CORPORATE OFFICER RESPONSIBILITIES




The RM-Plan must establish the VSA and responsible corporate officer
roles in very specific terms.  The required topics include:  the
qualifications and corporate position of the responsible corporate
officer and the VSA or VSAs; the ability of the responsible corporate
officer to support RAMP and the VSA function; the division of
technical responsibilities among multiple VSAs, if used; and the
extent of VSA involvement in every individual RAMP activity.
The plan normally presents the task-by-task description of VSA
duties as an integral part of the material on configuration control
and collection of evidence.


The RM-Plan names the person or persons occupying the VSA role
and summarizes briefly the qualifications and experience of each.
 Any person representing the product as a VSA must have completed
the Center training program.  (As noted earlier, the approval
of an RM-Plan confers Center recognition upon the VSAs referenced
in the plan as product representatives.)  The description of each
VSA's corporate position should cover both line management and
matrix management responsibilities.  Any intended use of contractors
or part-time employees as VSAs should be noted and explained.


There should be a general statement of the vendor's strategy for
assuring that the VSA or VSAs can:  track all aspects of the revision
process; confirm the findings of security analysis; influence
product changes; assure the accuracy and completeness of evidence;
and represent the product effectively to the Center.  If multiple
VSAs are utilized, the RM-Plan explains the reasons for this approach
and describe the primary areas of VSA responsibility in such a
fashion that the Center can associate one and only one VSA with
each element of the RAMP process.


The task-by-task description of VSA duties must cover for each
activity in RAMP:  1)  the share of work conducted personally
by a VSA;


2) the extent of VSA supervisory authority over the given task;
 3) the ability of a VSA to influence how work is done and what
outputs are produced; 4) the arrangements whereby a VSA can evaluate
the adequacy of procedures and accuracy of data; and 5) the terms
of VSA access to all information used in and generated by the
task.


The RM-Plan should emphasize VSA involvement in the CCB function,
the CRB function, the configuration audit, and the presentation
and defense of evidence.  The plan should name the VSA who serves
as a CCB member and show how this function allows the VSA to control
product changes through direct input to CCB decisions and through
the veto power of the responsible corporate officer.  VSA involvement
with the CRB is discussed similarly.  The plan describes VSA responsibilities
for producing the RMR and representing the product to the TRB.
 It names the VSA or VSAs who serve as configuration auditor(s)
or audit supervisors.  The RM-Plan must confirm that VSAs have
access to Dockmaster and are responsible for tracking Criteria
interpretation activity.


The RM-Plan must describe how the responsible corporate officer
will support the RAMP process and serve as the point of vendor
accountability to the Center.  This description covers:  the power
of the responsible corporate officer to make decisions and corporate
commitments on behalf of RAMP; the extent of responsible corporate
officer supervisory authority over the VSA(s) and over the operating
groups involved in RAMP tasks; the influence of the responsible
corporate officer over product changes; the role of the responsible
corporate officer as the vendor's contact with the BPOC; and the
ability of the responsible corporate officer to influence the
corporate response to failures in the product or the RAMP process.
 As described in Section 6, the responsible corporate officer
must be in a position to assume full responsibility for the content
of RMR submissions.


The RM-Plan must name the lead VSA, if there are multiple VSAs,
and describe all lines of authority among the responsible corporate
officer, the lead VSA, and other VSAs.  There should be an overview
of RAMP program administration showing how RAMP fits into the
corporate management structure.  The RM-Plan should include a
corporate organization chart and a personnel directory listing
the department and job title of all persons who might contact
the Center on the subject of RAMP.  The organization chart should
be abbreviated horizontally by showing only the portion of the
corporate hierarchy that contains the responsible corporate officer,
the VSAs, all CCB and CRB members, and all operating groups with
major involvement in RAMP.
7.10 EXCEPTION HANDLING



The RM-Plan must describe any and all exception handling procedures
that may be used in the development of the product.  Exception
handling refers here to actions outside the normal cycle of releases,
not exceptions to RAMP practices.  Under no circumstances are
interruptions in configuration management allowable.


Specifically, the RM-Plan must address the vendor's response to
product and process failures.  The failures that can occur for
a product in RAMP fall into three categories, as follows.


   Bug: Improper execution of an acceptable design.


   Flaw: Incorporation of an inadequate design decision.


Breakdown of process: Deficiency in the security analysis and/or
configuration management procedures that confer RAMP assurance.


These failures can have widely varying impacts upon the responsible
vendor, the user community, and the product rating.  Bugs and
flaws are of greatest immediate concern to users.  However, breakdowns
of process tend to have the greatest long-term impacts on product
ratings and continued RAMP applicability.  Errors can usually
be located and corrected if the process remains pure, but RAMP
assurance may not be recoverable if the process fails.  Section
8 discusses the response of the Center to these types of failures.


The primary focus of exception handling is the management of system
bugs.  The Center recognizes that at the C1 through B1 rating
levels (which are features-oriented rather than assurance-oriented),
a product may contain implementation errors that are undetected
by evaluation and that may be exploitable under some circumstances.
 It is not acceptable to pass responsibility for vulnerability
management on to system users.  Vendors should therefore plan
ahead for the possibility of bugs and should develop procedures
for correcting bugs with minimum delay and risk to users.


The following are suggested steps to deal with a potentially exploitable
bug once identified.  The vendor:

 • 1) immediately deploys a repair and recovery team to analyze
and solve the problem







2) contains information regarding the bug in order to minimize
risk to operational systems


3) provides immediate notice to the TPOC so that the Center can
take any necessary steps to assure the protection of system users


4) undertakes the replacement or repair of all operational systems
that contain the bug


5) reports progress to the Center on a weekly basis


6) packages the repair or replacement in such a fashion that the
exploitable bug is not easily determinable from the repair distribution.


The RM-Plan must explain how these and related tasks will be accomplished
in case of product failure, and must state corporate policies
for using exception-fix procedures and for correcting bugs in
subsequent scheduled product releases.


The RM-Plan must also describe the vendor's internal procedures
for restoring the RAMP process if there is a process failure (and
if the Center determines that the process can potentially be restored).
 These procedures include:  establishing the precise nature of
the error or breakdown and the reasons for its occurrence; tracing
the full ramifications of the problem for all affected product
versions; conducting security analysis to establish corrective
measures and verify product trust; and reestablishing the unbroken
trail of evidence linking to the evaluated product.
7.11 NUMBERING AND RETIREMENT OF PRODUCT VERSIONS



A product release that includes any correction for a bug or flaw
becomes a different product from the standpoint of the Center
and the user community.  The vendor must develop a product identification
system that reflects this fact.  A favorable approach is an alphanumeric
system in which the numeric portion (typically involving decimals)
denotes the product version as released and the letter suffix
denotes corrections.  For example, version 1.0 might be the original
product subjected to  evaluation; versions 1.1, 1.2, and so on
might be successive releases in RAMP; and versions 1.0a and 1.1a
might be the first two versions after a correction has been added.
 This system yields a two-dimensional product flow as illustrated
in Figure 6.


In this example, a system bug is discovered after the second version
(1.1) has been released.  The development of a correction for
this bug yields two new products, 1.0a and 1.1a.  Then another
bug is identified after version 1.2 has been released.  This bug
is corrected in

 • 1.1 and 1.2, yielding products 1.1b and 1.2b, but is not corrected
in 1.0 because the original product version has been retired (as
defined below).  The two diagonal arrows in the diagram indicate
that each bug correction is incorporated in the next scheduled
release.  Every RM-Plan should establish a product identification
system that has this degree of flexibility and comprehensiveness.







The RM-Plan should also indicate that the vendor will inform the
Center whenever a rated product version is retired.  Retirement
is defined in this context as the point at which a vendor no longer
offers a product version for sale and no longer provides bug fixes
and related services for that version.  The Center needs to be
informed of retirement decisions so that the affected products
can be shifted to a separate section of the EPL.
7.12 MANAGEMENT OF RM-PLAN



Previous discussion has suggested why RM-Plans may change


occasionally and how changes are effected.  Due to the possibility
of change, the RM-Plan must describe how the plan itself is managed.
 This discussion should indicate how the vendor establishes a
need to change the RM-Plan; how the vendor formulates and proposes
specific changes; and how the vendor assures compliance with RM-Plan
changes when in place.
8. RAMP TERMINATION, SANCTIONS, AND RISKS

8.1 OVERVIEW OF RAMP PROCESS



Figure 7 depicts graphically various processes from the initial
evaluation and VSA training to the establishment and application
of RAMP for a product.  (Figure 7 is an expansion of Figure 2).
 The starting points for establishing RAMP are the original product
and the training of vendor representatives as VSAs.  The vendor
develops an RM-Plan and obtains approval for the plan before the
Center starts the phase of product evaluation.  Figure 7 emphasizes
that the RAMP process builds upon an evaluated product and upon
the evidence yielded by evaluation.


The RM-Plan establishes a configuration management framework for
the analysis, design, implementation, and approval of product
changes.  The VSAs participate in these rating maintenance actions
and assure that security concerns dominate all decisions affecting
the product.  The outputs of rating maintenance consist of approved
product changes and evidence supporting the changes.  The VSAs
summarize this evidence in an RMR, which is submitted to the TPOC
and reviewed by the Center community.  The TRB then receives and
reviews the RMR, examines the VSAs on the evidence, and recommends
that the product rating be extended (or not extended) to the new
release.  The cycle ends with approval or disapproval of the rating
by the Chief of the Product Evaluation Division and listing of
the new approved release on the EPL.  The TPOC is the interface
between the vendor and the Center in all technical communications
except the interim and aperiodic reviews and the TRB examination.
 (The diagram omits the responsible corporate officer and BPOC
roles.)


There is no fixed limit on the number of revision cycles that
can be covered by an application of RAMP.  The termination of
a RAMP process can be either voluntary or involuntary from the
vendor's standpoint.  A vendor might choose to terminate RAMP
because the product is being discontinued; because no further
revisions are planned; or because rating maintenance is not considered
essential for further releases.


Applications of RAMP tend to have a natural life span ending with
the vendor's introduction of a replacement product that requires
 evaluation and a new RAMP process.  Voluntary exits from RAMP
are usually pre-arranged to occur at the end of a rating maintenance
cycle.


The intermediate cases are situations in which a vendor desires
to continue RAMP but needs to implement product changes that RAMP
cannot cover.  Given a commitment to the changes, the vendor must
decide whether to terminate RAMP permanently or undergo reevaluation
to start another RAMP process.  The requirement for such a choice
might be established by the VSAs when analyzing changes during
a revision cycle; by the vendor when planning future changes;
or by the Center when reviewing the vendor's future change analysis
in an RMR.  Advance notice of the decision point obviously benefits
the vendor by minimizing wasted effort and allowing timely placement
of the product in the queue for a reevaluation (if future rating
maintenance is intended).  Consequently, the vendor should supply
as much information as possible to the Center in each future change
analysis.  The Center attempts to provide an interval of at least
one revision cycle within which the vendor can seek reevaluation
while rating maintenance is still under way.  However, the Center
cannot guarantee that this outcome will occur, or that any given
rating maintenance cycle will be successful.
8.2 OVERVIEW OF RAMP PROCESS



Involuntary termination of RAMP is associated with failure in
the product or process.  Failures can be identified through program
reviews, TRB examinations, or other mechanisms.  The Center response
to an identified failure depends upon the nature of the problem
and how it occurred.


The Center terminates permanently the use of RAMP for a product
if the vendor has knowingly misrepresented any aspect of the product
or its RAMP process.  The VSA or VSAs responsible for the misrepresentation
will no longer be recognized by the Center as representatives
of any product.  The Center permanently lifts the rating of the
product release for which the misrepresentation occurred and the
ratings of any later versions dependent upon that release for
rating maintenance.  Furthermore, the Center activates the aperiodic
review process to investigate the possibility of misrepresentations
or other errors in earlier releases.  The product rating is then
rolled back at least to the earliest known breakdown of RAMP assurance.


When an inadvertent failure is identified, the Center may or may
not allow the vendor to rebuild RAMP assurance and continue the
rating maintenance process.  If a failure is identified during
a TRB review, the vendor may or may not be allowed to fix the
failure and resubmit the product depending on the nature of the
failure.  A vendor usually is permitted and able to fix a bug
(implementation error) while rating maintenance is under way.
 The Center treats a system flaw (design error) similarly to a
bug unless its correction requires an architectural change that
RAMP cannot accommodate.  The Center does not approve any new
ratings until all identified bugs and flaws have been eliminated,
but normally does not suspend past ratings so long as the RAMP
process is unimpeached and the vendor makes every reasonable effort
to protect the user community.  A breakdown of process, such as
a loss of product evidence, tends to have the most serious consequences
for rating maintenance even if no deliberate malfeasance is involved.
 The Center usually lifts the ratings for all affected releases
at least temporarily, and determines on the basis of individual
circumstances whether and how the vendor can reconstruct the RAMP
process.
8.3 RISKS OF RAMP PARTICIPATION



There are no sanctions in RAMP that apply retroactively to products
evaluated by the Center.  Choosing to participate in RAMP cannot
place an existing product rating in jeopardy.  Thus, a vendor's
decision to initiate a RAMP process can only create the following
risk.  There is a chance that the net costs incurred to participate
in RAMP will not yield the desired ratings for product revisions,
and hence may be viewed as financial losses.


Section 1 has suggested the ways in which RAMP participation can
create net monetary costs for a vendor.  A major determinant is
the extent to which a vendor's business practices need to be altered
to meet RAMP requirements for security analysis and configuration
management.  When evaluating whether these costs and adjustments
are supportable, a vendor should be aware of the following considerations.

 • 1) The chance that an application of RAMP will be unsuccessful
can be greatly reduced by approaching the program constructively
and conscientiously.  This means allocating the time of highly
capable and experienced personnel to the RAMP process; applying
scrupulously the RAMP principles of security dominance and configuration
management; and keeping the Center as well-informed as possible
about upcoming product changes.







2) The net costs of creating and pursuing a RAMP process can be
viewed as an investment with potential returns extending well
beyond the given product.  The capabilities developed in one RAMP
experience are valuable not only for other applications of the
program but also for the creation of new trusted products from
start to finish.


Regarding the second point, the value of in-house security wisdom
is increasing very rapidly for computer vendors.  Various factors
are making access to the expanding market for trusted systems
more and more dependent upon the availability of this resource.
 RAMP is the appropriate context and focus for developing security
analysis capability.
APPENDIX

SUMMARY OF RAMP REQUIREMENTS



This appendix summarizes the vendor's and the Center's requirements
for RAMP.  These requirements are linked to the timing of the
product evaluation and are  listed in approximate order of occurrence,
under the phase of the evaluation process in which they occur.
 A vendor failing to satisfy these requirements loses the opportunity
to participate in RAMP until such time as the product in question
is reevaluated.  The Center reserves the right to deny a rating
and/or discontinue the Rating Maintenance Phase at any time.
PREEVALUATION PHASE


 • 1. Vendor establishes an intent to participate in RAMP in
the evaluation package/proposal for a given product.





VENDOR ASSISTANCE PHASE/DESIGN ANALYSIS PHASE


 • 1. The vendor must identify and maintain a responsible corporate
officer.  The responsible corporate officer represents the vendor
in administrative matters, serves as the point of vendor accountability
to the Center, is able to make decisions and corporate commitments
on behalf of RAMP, and supports the technical role of the VSA.







2. The vendor must complete training of one or more Vendor Security
Analysts (VSAs) before implementation of the vendor's Rating Maintenance
Plan but not later than completion of the IPAR.  The vendor must
provide for VSA access to the Center's Dockmaster computer system
at the time VSA training begins.  Whenever a vendor uses more
than one VSA, a lead VSA will be identified by the vendor.


3. The Center will provide RAMP training for VSAs.


4. The vendor must develop, have approved, and implement a


Rating Maintenance Plan (RM-Plan).  The RM-Plan must be approved
by the Center prior to its implementation but not later than completion
of the IPAR.  The approved RM-Plan must be implemented before
development begins on the version that will supersede the evaluated
version.

 • 5. The Center will review the vendor's RM-Plan for purposes
of approving the RM-Plan.





EVALUATION PHASE



1. The vendor must maintain a responsible corporate officer.


2. The vendor must maintain one or more Center-trained Vendor


Security Analysts (VSAs) once the vendor's RM-Plan has been implemented.
 The vendor must provide for VSA access to the Center's Dockmaster
computer system.  Whenever a vendor utilizes more than one VSA,
a lead VSA will be identified by the vendor.


3. The Center will provide RAMP training for VSAs.


4. The vendor must complete implementation of the


Center-approved Rating Maintenance Plan (RM-Plan) and must follow
the business practices outlined in the RM-Plan.  The RM-Plan must
be implemented before development begins on the version that will
supersede the evaluated version.  Any changes to the RM-Plan must
be approved by the Center and must be made according to the provisions
within the approved RM-Plan.


5. The vendor must conduct, for his own purposes, an initial


RAMP audit to assure that security feature functionality and assurances
are being maintained by adherence to all the procedures established
in the vendor's approved RM-Plan.


6. The Center evaluation team will review the results of the vendor's
initial RAMP audit to ensure the vendor's RAMP process follows
the procedures outlined in the vendor's RM-Plan.


7. The Center assigns a Technical Point of Contact and a Business
Point of Contact before completion of the evaluation phase.  The
TPOC advises and coordinates the use of RAMP for the given product.
 The BPOC handles administrative and programmatic aspects of the
process.
RATING MAINTENANCE PHASE


 • 1. The vendor must maintain a responsible corporate officer.








2. The vendor must maintain one or more Center-trained Vendor
Security Analysts (VSAs) once the vendor's RM-Plan has been implemented.
 The vendor must provide for VSA access to the Center's Dockmaster
computer system.  Whenever a vendor uses more than one VSA, a
lead VSA will be identified by the vendor.

 • 3. The Center will provide RAMP training for VSAs.







4. The Center maintains a Technical Point of Contact and a Business
Point of Contact.


5. The vendor must provide product instruction for the Center
Technical Point of Contact, as needed throughout the Rating Maintenance
Phase.  This is to include product documentation, vendor provided
classes, and hands-on system access time.


6. The vendor will provide quarterly informal status reports to
the Technical Point of Contact via the Center's Dockmaster system
throughout the Rating Maintenance Phase.


7. The vendor must conduct, for each RAMP cycle, at least one
RAMP audit to assure that security feature functionality and assurances
are being maintained by adherence to all the procedures established
in the vendor's approved RM-Plan.

 • 8. The Center Technical Point of Contact will review the results
of the vendor's RAMP audit to ensure the vendor's RAMP process
follows the procedures outlines in the vendor's RM-Plan.







9. The vendor will submit concurrently to the Center the following
documents for each version of an evaluated product for which the
vendor desires to have the rating maintained via RAMP:

 • a) Rating Maintenance Report (RMR)







b) Rating Maintenance Plan (RM-Plan) with change bars


c) Final Evaluation Report with change bars


d) Final Evaluation Report with integrated changes


e) Proposed product description for EPL


The documents intended for public release are the final evaluation
report with integrated changes and the proposed product description
for EPL.

 • 10. The Center will review the vendor's documents for purposes
of extending the rating to the specific release and for placement
on the Evaluated Products List.







11. The vendor's RAMP process is subject to two types of reviews
(Interim Reviews and Aperiodic Reviews) by the Center.  Both types
of program review have the purpose of assuring that security feature
functionality and assurances are being maintained by adherence
to all the procedures established in the vendor's approved RM-Plan.
GLOSSARY



BPOC  -  Business Point of Contact (Center).


CCB  -  Configuration Control Board.


  Center -  National Computer Security Center.


  CF   -  Code Freeze.


  CI   -  Configuration Item.


  COMPUSEC - Computer Security.


  CRB  -  Configuration Review Board.


  Criteria -  Same as TCSEC.


  Dockmaster - A Center computer system serving


the evaluation community.


  ECO  -  Engineering Change Order.


  EPL  -  Evaluated Products List.


  Evaluated Product - A product version that has undergone evaluation
by the Center. (By convention, excludes products assigned D ratings.
 An evaluated product is always a rated product, but the reverse
is not always true for products in RAMP.)


  FER  -  Final Evaluation Report.


  Interpretations - Published Center Interpretations of the TCSEC.


  IPAR  -  Initial Product Assessment Report.


  PTR  -  Preliminary Technical Report.


  RAMP -  Rating Maintenance Phase.


  Rated Product - A product version with a TCSEC rating and a
listing on the EPL, obtained either through evaluation or RAMP.
 (By convention, excludes products with D ratings.)


  RM-Plan -  Rating Maintenance Plan.


  RMR  - Rating Maintenance Report.


  SIR  - Service Improvement Request.


  TCB  - Trusted Computing Base.


  TCSEC  - Department of Defense Trusted Computer System Evaluation
Criteria (DoD 5200.28-STD); the Criteria against which products
are evaluated to establish security ratings.


TPOC  - Technical Point of Contact (Center).


  TRB  - Technical Review Board (Center).


  VSA  - Vendor Security Analyst.



BIBLIOGRAPHY



Department of Defense Trusted Computer System Evaluation Criteria,
December 1985 (DOD 5200.28-STD).


Brown, Leonard, R. "Specification for a Canonical Configuration
Accounting Tool," Proceedings of the 10th National Computer
Security Conference, 21 September 1987, p. 84.